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

Question

在从iTunes获得的崩溃日志中，我无法理解要深入研究哪个线程的信息。

它说线程16崩溃了。因此，我是否必须检查[FreePlayMenuScene dealloc]中的代码，还是有可能原因位于另一个线程中？例如，在线程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

非常感谢。

Answer 1

好吧，永远不要说永远:总是会有这样的情况，一个线程执行某项操作会导致另一个线程抛出异常并崩溃。但是，当发生这种情况时，您通常会遇到某种计时问题或争用情况，并且当崩溃发生时，麻烦的线程总是位于同一位置是很罕见的。在那些情况下，错误的线程会“设置陷阱”，然后崩溃的线程会陷入其中。

就您而言，我认为日期格式与它无关，除非您在多个线程上共享一个NSDateFormatter(不要，这不是线程安全的)。

由于异常是EXC_BAD_ACCESS(访问无效的内存地址)，并且它发生在[CCScheduler unscheduleAllSelectorsForTarget:]中，因此我猜测是一个错误的指针潜伏在Cocos2D场景图中的某个地方。也许您添加了一个节点，该节点已被过度释放？很难说。在这种情况下，不一定是另一个线程有问题，但是看起来问题是由其他一些代码引起的，当该代码偶然出现在该代码上时会引起问题。