How to understand this crash log

Question

I got (in ITC) below presented crash report for my first Mac App Store app. Using knowledge founded on Stackoverflow I tried to symbolicate this log, but (using atos and otool) I was only able to read last (20) line (which means start (in My App) + 52. I really don't know how to interpret lines above, and how to find cause of crash.

Process:         My App [270]
Identifier:      com.mycompany.myapp
Version:         1.0.0 (1.0.0)
App Item ID:     568750000
App External ID: 11410000
Code Type:       X86-64 (Native)
Parent Process:  launchd [143]
User ID:         501

Date/Time:       2012-11-07 19:21:11.365 -0200
OS Version:      Mac OS X 10.8.2 (12C60)
Report Version:  10

Per-App Interval Since Last Report:  1232 sec
Per-App Crashes Since Last Report:   1

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib                 0x00007fff877a5256 objc_msgSend + 22
1   com.apple.AppKit                0x00007fff8dac6e27 -[NSOutlineView _delegate_isGroupRow:] + 66
2   com.apple.AppKit                0x00007fff8da46878 -[NSTableView _isGroupRow:] + 81
3   com.apple.AppKit                0x00007fff8da41fad -[NSTableView _isSourceListGroupRow:] + 56
4   com.apple.AppKit                0x00007fff8da418e8 -[NSTableView rectOfRow:] + 288
5   com.apple.AppKit                0x00007fff8da5b3cb _NSTVVisibleRowsForUpdate + 296
6   com.apple.AppKit                0x00007fff8da5aa85 -[NSTableRowData _unsafeUpdateVisibleRowEntries] + 96
7   com.apple.AppKit                0x00007fff8da5a8a1 -[NSTableRowData updateVisibleRowViews] + 119
8   com.apple.AppKit                0x00007fff8da6e463 -[NSTableRowData _idleUpdateVisibleRows] + 66
9   com.apple.CoreFoundation        0x00007fff87547da4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20
10  com.apple.CoreFoundation        0x00007fff875478bd __CFRunLoopDoTimer + 557
11  com.apple.CoreFoundation        0x00007fff8752d099 __CFRunLoopRun + 1513
12  com.apple.CoreFoundation        0x00007fff8752c6b2 CFRunLoopRunSpecific + 290
13  com.apple.HIToolbox             0x00007fff830a30a4 RunCurrentEventLoopInMode + 209
14  com.apple.HIToolbox             0x00007fff830a2e42 ReceiveNextEventCommon + 356
15  com.apple.HIToolbox             0x00007fff830a2cd3 BlockUntilNextEventMatchingListInMode + 62
16  com.apple.AppKit                0x00007fff8d8d8613 _DPSNextEvent + 685
17  com.apple.AppKit                0x00007fff8d8d7ed2 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 128
18  com.apple.AppKit                0x00007fff8d8cf283 -[NSApplication run] + 517
19  com.apple.AppKit                0x00007fff8d873cb6 NSApplicationMain + 869
20  com.mycompany.myapp             0x000000010f29ce1c 0x10f29b000 + 7708

Yurev

It's segmentation fault, probably not occurred in one of your method.So you somehow left the table view in an inconsistent state. – Carreon

Thank you for your help, but I have a large number of TableView and OutlineView in my app. Without identifying the window this report is completely unusable for me (like other report from osx :( ). – Yurev

Answer 1

Reading stack frames that aren't in your code often borders on reading tea leaves, but in this case, it's pretty clear what happened.

I'm going to read your crash log to you, translating as I go along.

The stack is built up from the bottom up (just like stacks in the real world). I'll cut to the chase:

10  com.apple.CoreFoundation        0x00007fff875478bd __CFRunLoopDoTimer + 557
9   com.apple.CoreFoundation        0x00007fff87547da4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 20

A timer fired.

8   com.apple.AppKit                0x00007fff8da6e463 -[NSTableRowData _idleUpdateVisibleRows] + 66
7   com.apple.AppKit                0x00007fff8da5a8a1 -[NSTableRowData updateVisibleRowViews] + 119
6   com.apple.AppKit                0x00007fff8da5aa85 -[NSTableRowData _unsafeUpdateVisibleRowEntries] + 96
5   com.apple.AppKit                0x00007fff8da5b3cb _NSTVVisibleRowsForUpdate + 296

In this timer (which is presumably set to fire during idle time), the table view attempts to update its knowledge of which rows are visible.

(The last frame is the one that clarifies that it's updating which rows are visible, not updating the rows that are visible. You can tell this from the wording of the function's name.)

4   com.apple.AppKit                0x00007fff8da418e8 -[NSTableView rectOfRow:] + 288

To determine whether a row is visible, the view needs to figure out where that row is within its bounds (presumably to intersect with its visible rectangle within the scroll view).

Toward that end, the table view is attempting to figure out the characteristics of this row:

3   com.apple.AppKit                0x00007fff8da41fad -[NSTableView _isSourceListGroupRow:] + 56

Is it a source list group row?

2   com.apple.AppKit                0x00007fff8da46878 -[NSTableView _isGroupRow:] + 81

Is it any group row at all?

1   com.apple.AppKit                0x00007fff8dac6e27 -[NSOutlineView _delegate_isGroupRow:] + 66

Let's ask the delegate.

0   libobjc.A.dylib                 0x00007fff877a5256 objc_msgSend + 22

Attempting to send a message. This is where your process crashed.

So, the crash occurred while the outline view was trying to send a message to its delegate.

From this, we can derive three facts:

1. The view in question is an outline view, not a non-outline table view. (Frame #1 proves this. A regular table view isn't an NSOutlineView.) This alone may identify the view involved, but if it doesn't, no biggie, because we have another fact that may narrow it down.
2. The outline view in question has a delegate. This alone may identify the outline view involved, but if it doesn't, no biggie, because the problem isn't with the view at all.
3. The problem is that the object that is the view's delegate is insufficiently owned. It dies prematurely before the outline view can send it the message we saw in the stack trace.

Use Instruments's Zombies template to determine which object the outline view is trying to talk to, and to look over the history of that object to find the undue or unbalanced release that killed it. You probably need to add a strong ownership of that object somewhere.

Hillie

I really thank you for your impressive explanation. This allowed me to better understand this log. Now I'll try to find where the bug is. – Yurev

Peter, this is one of the most helpful posts I have ever come across! This is exactly what was happening to me, however with just a plain table view, instead of an outline view. My error was that I forgot to set my table view's delegate and data source to nil before letting ARC release my view controller. – Gunpoint

I didn't have the strong _delegate_ clue in my stack trace but it ended up being the a delegate issue. I pushed a view controller onto the navigation stack and set it as the tab bar's delegate. Then I forgot to set the delegate to nil before I popped that view controller. Then when I tapped on the tab bar, boom, because it's tying to access a view controller that no longer exists. To me it's odd that there's not an exception thrown in these cases. – Disconformity