3

我正在使用 crittercism 来获取有关我的应用程序的崩溃报告。它工作得很好,但是我遇到了一个堆栈跟踪崩溃,这并不是很有帮助。

0   libobjc.A.dylib 0x3b16c5b0 objc_msgSend + 16
1   Foundation 0x33d6b0f5 __NSThreadPerformPerform + 461
2   CoreFoundation 0x33429683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
3   CoreFoundation 0x33428ee9 __CFRunLoopDoSources0 + 213
4   CoreFoundation 0x33427cb7 __CFRunLoopRun + 647
5   CoreFoundation 0x3339aebd CFRunLoopRunSpecific + 357
6   CoreFoundation 0x3339ad49 CFRunLoopRunInMode + 105
7   GraphicsServices 0x36f712eb GSEventRunModal + 75
8   UIKit 0x352b0301 UIApplicationMain + 1121
9   myapp 0x00024c2f main (main.m:14)

坠机是象征性的,但没有任何信息可以告诉我坠机的确切位置。我认为它可能是一个过早发布的对象,但由于它是一个随机错误而且我不知道它发生在哪里,所以很难追踪它。如何将此堆栈跟踪或崩溃报告转换为人类可读的?

4

1 回答 1

1

这次崩溃几乎与我目前主要的导致头痛的崩溃完全相同,我不知道该怎么办。我的崩溃日志中唯一的变化是main (main.m:6)你的main (main.m:14).

到目前为止,我发现了这个:

接受的答案表明它可能与滥用performSelector.

这家伙也有同样的崩溃,但没有建议的解决方案:

还有其他类似的崩溃日志有一个奇怪的补充:

...
CoreFoundation 0xXXXXXXXX -[NSObject performSelector:withObject:] + XX <- additional line
Foundation     0xXXXXXXXX __NSThreadPerformPerform + XXX
CoreFoundation 0xXXXXXXXX __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + XX
...

这再次表明它与 相关performSelector,但这仍然是猜测。

于 2013-04-04T09:22:11.157 回答