崩潰的線程是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崩潰報告中唯一重要的線程嗎？

回答

相關問題