崩溃的线程是iOS崩溃报告中唯一重要的线程吗？

我无法理解要从iTunes获取的崩溃日志中挖掘哪些线程的信息。崩溃的线程是iOS崩溃报告中唯一重要的线程吗？

它说线程16崩溃了。那么，我是否必须检查[FreePlayMenuScene dealloc]中的代码，还是有可能原因位于另一个线程中？例如，在Thread 0中提到了NSDateFormatter，如果相关与否，我不明白。

要问这是一个通用的问题，在阅读崩溃日志时，我们是否应该只检查崩溃的线程或在其他线程中可能有帮助的信息？不幸的是，我在这里或任何地方都找不到类似的问题。

下面的代码：

Exception Type: EXC_BAD_ACCESS (SIGSEGV) 
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000 
Crashed Thread: 16 

Thread 0 name: Dispatch queue: com.apple.main-thread 
Thread 0: 
0 libicucore.A.dylib    0x3333feac udat_close + 0 
1 CoreFoundation     0x37cd60d0 __CFDateFormatterDeallocate + 12 
2 CoreFoundation     0x37c513ce CFRelease + 290 
3 Foundation      0x354795ea -[NSDateFormatter _clearFormatter] + 22 
4 Foundation      0x354a4b44 -[NSDateFormatter dealloc] + 52 
5 libobjc.A.dylib     0x34b95484 
6 CoreFoundation     0x37c5343c _CFAutoreleasePoolPop + 12 
7 Foundation      0x35500978 __NSThreadPerformPerform + 600 
8 CoreFoundation     0x37ce5680   9 CoreFoundation     0x37ce4ee4 __CFRunLoopDoSources0 + 208 
10 CoreFoundation     0x37ce3cb2 __CFRunLoopRun + 642 
11 CoreFoundation     0x37c56eb8 CFRunLoopRunSpecific + 352 
12 CoreFoundation     0x37c56d44 CFRunLoopRunInMode + 100 
13 GraphicsServices    0x345592e6 GSEventRunModal + 70 
14 UIKit       0x345c32fc UIApplicationMain + 1116 
15 AClockworkBrain     0x0000365a main (main.m:13) 
16 AClockworkBrain     0x0000361c start + 36 

... 
... 

Thread 16 Crashed: 
0 AClockworkBrain     0x001d7cd2 -[CCScheduler unscheduleAllSelectorsForTarget:] + 126 
1 AClockworkBrain     0x001ca8f8 -[CCNode unscheduleAllSelectors] + 48 
2 AClockworkBrain     0x001c9526 -[CCNode cleanup] + 38 
3 AClockworkBrain     0x001f1016 -[CCArray makeObjectsPerformSelector:] + 54 
4 AClockworkBrain     0x001c9550 -[CCNode cleanup] + 80 
5 AClockworkBrain     0x001f1016 -[CCArray makeObjectsPerformSelector:] + 54 
6 AClockworkBrain     0x001c9550 -[CCNode cleanup] + 80 
7 AClockworkBrain     0x001c9cf4 -[CCNode removeAllChildrenWithCleanup:] + 156 
8 AClockworkBrain     0x00078ecc -[FreePlayMenuScene dealloc] (FreePlayMenuScene.m:776) 
9 Foundation      0x35500e4c __NSFinalizeThreadData + 1004 
10 CoreFoundation     0x37ce0f7e __CFTSDFinalize + 62 
11 libsystem_c.dylib    0x37ab9128 _pthread_tsd_cleanup + 172 
12 libsystem_c.dylib    0x37ab8dfe _pthread_exit + 114 
13 libsystem_c.dylib    0x37ad2160 pthread_exit + 24 
14 Foundation      0x35489226 +[NSThread exit] + 6 
15 Foundation      0x35500696 __NSThread__main__ + 998 
16 libsystem_c.dylib    0x37ac630e _pthread_start + 306 
17 libsystem_c.dylib    0x37ac61d4 thread_start + 4

非常感谢。

来源

2012-10-15 dimitrios

好吧，永远不要说永远不会说：总有一种情况，一个线程会导致另一个线程抛出异常并崩溃。然而，当发生这种情况时，你通常会遇到某种时间问题或竞赛状况，并且当发生崩溃时，难以解决的问题线程总是处于相同的地方。在这些情况下，坏线程“设置陷阱”，然后崩溃线程陷入它。我不认为日期格式与它有任何关系，除非你在多个线程上共享一个NSDateFormatter（不要，它不是线程安全的）。由于异常是EXC_BAD_ACCESS（访问无效的内存地址），并且发生在[CCScheduler unscheduleAllSelectorsForTarget:]中，所以我猜测Cocos2D场景图中某处存在坏指针。也许你添加了一个过度发布的节点？很难说。在这种情况下，它不一定是另一个有问题的线程，但看起来问题是由其他代码段设置的，当代码偶然发现时会导致问题。

来源

2012-10-15 19:53:20 benzado

最重要的是实际坠毁的线程。但请记住，崩溃可能会受到当时其他线程中发生的情况的影响。但是，在大多数情况下，只有坠毁的线程是相关的。我担心其他线程，如果崩溃实际上涉及到跨多个线程完成的事情，或者如果事情在多个线程中并且不应该。

在您发布的日志中，恰好碰巧发生崩溃时，日期格式化程序正在主线程上解除分配。可能根本不涉及FreePlayMenuScene问题。

来源

2012-10-15 19:53:30 rmaddy

崩溃的线程是iOS崩溃报告中唯一重要的线程吗？

回答

相关问题