objective-c - 如何理解这个崩溃日志

Question

我(在 ITC)收到了我的第一个 Mac App Store 应用程序的崩溃报告。使用基于 Stackoverflow 的知识，我尝试符号化此日志，但(使用 atos 和 otool)我只能阅读最后 (20) 行(这意味着 start (in My App) + 52。我真的不知道如何解释上面的行，以及如何找到崩溃的原因。

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

Answer 1

阅读不在您的代码中的堆栈帧通常类似于阅读茶叶，但在这种情况下，很清楚发生了什么。

我将向您朗读您的崩溃日志，边读边翻译。

堆栈是自下而上构建的(就像现实世界中的堆栈一样)。我开门见山:

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

计时器启动。

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

在此计时器中(大概设置为在空闲时间触发)， TableView 尝试更新其对哪些行可见的了解。

(最后一帧阐明它正在更新哪些行是可见的，而不是更新可见的行。您可以从函数名称的措辞中看出这一点。)

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

要确定一行是否可见， View 需要确定该行在其边界内的位置(大概与 ScrollView 中的可见矩形相交)。

为此， TableView 试图找出这一行的特征:

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

它是源列表组行吗？

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

它是任何组行吗？

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

让我们问问代表。

0   libobjc.A.dylib                 0x00007fff877a5256 objc_msgSend + 22

正在尝试发送消息。这是您的进程崩溃的地方。

因此，当大纲 View 试图向其委托(delegate)发送消息时发生崩溃。

由此，我们可以得出三个事实:

1. 有问题的 View 是大纲 View ，而不是非大纲 TableView 。 (第 1 帧证明了这一点。常规 TableView 不是 NSOutlineView。)仅此一项就可以识别所涉及的 View ，但如果没有，也没什么大不了的，因为我们还有另一个事实可以缩小它的范围。
2. 有问题的大纲 View 有一个委托(delegate)。仅此一项就可以确定所涉及的大纲 View ，但如果没有，也没什么大不了的，因为问题根本不在于 View 。
3. 问题是作为 View 委托(delegate)的对象没有被充分拥有。它在大纲 View 可以向它发送我们在堆栈跟踪中看到的消息之前过早死亡。

使用 Instruments 的 Zombies 模板来确定大纲 View 试图与哪个对象对话，并查看该对象的历史以找到杀死它的不当或不平衡的释放。您可能需要在某处添加该对象的强所有权。