如何理解这个崩溃日志 [英] How to understand this crash log

查看:260
本文介绍了如何理解这个崩溃日志的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我(在ITC)下面显示我的第一个Mac App Store应用程序的崩溃报告。
使用基于Stackoverflow的知识我试图象征这个日志,但(使用atos和otool)我只能读取最后(20)行(这意味着开始(在我的应用程序) 52
我真的不知道如何解释上面的行,以及如何找到崩溃的原因。

 过程:我的应用程序[270] 
标识符:com.mycompany.myapp
版本:1.0.0(1.0.0)
应用程序项目ID:568750000
App外部标识:11410000
代码类型:X86-64(原生)
父进程:launchd [143]
用户ID:501

日期/时间:2012-11-07 19:21:11.365 -0200
操作系统版本:Mac OS X 10.8.2(12C60)
报告版本:10

每个应用程序间隔最后报告:1232秒
每个应用程序崩溃从上次报告:1

崩溃的线程:0分派队列:com.apple.main线程

异常类型:EXC_BAD_ACCESS(SIGSEGV)
异常代码:EXC_I386_GPFLT


线程0崩溃::分派队列: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:离队:] + 128
18 com.apple.AppKit 0x00007fff8d8cf283 - [运行的NSApplication ] + 517
19 com.apple.AppKit 0x00007fff8d873cb6 NSApplicationMain + 869
20 com.mycompany.myapp 0x000000010f29ce1c 0x10f29b000 + 7708


解决方案

读取不在你的代码中的堆栈框架通常会读取茶叶,但在这种情况下,发生了什么事情。 p>

我要读取您的崩溃日志,翻译为我一起。



从底部向上(就像堆栈在现实世界中)。我将切换到追逐:


  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


在这个定时器(可能设置为在空闲时间内触发) ,表视图尝试更新其可见行的知识。



(最后一个框架是澄清它正在更新的框架行是可见的,而不是更新可见的行。你可以从函数名称的措辞来判断这一点。)


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


行是可见的,则视图需要确定该行在其边界内的位置(可能与其在滚动视图内的可见矩形相交)。



表视图试图找出此行的特征:


  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 




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



因此,大纲视图尝试向其委托发送消息时发生崩溃。



从这里,我们可以得到三个事实:


  1. 这个视图是一个大纲视图,概述表视图。 (frame#1证明了这一点,一个常规的表视图不是一个NSOutlineView。)这可以单独识别涉及的视图,但如果它不,没有biggie,因为我们有另一个事实,可以缩小它。 >
  2. 所讨论的大纲视图有一个委托。这单独可以识别涉及的大纲视图,但如果它不是,没有biggie,因为问题根本不是视图。

  3. 问题是,对象是视图的代理没有足够的所有权。

使用Instruments的Zombies模板来确定哪个对象大纲视图正在尝试与对象交谈,并查看该对象的历史,以找到杀死它的不当或不平衡的发布。您可能需要在某处添加该对象的强所有权。


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

解决方案

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.

这篇关于如何理解这个崩溃日志的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆