Is the crashed thread the only important one in an iOS crash-report?

I'm having trouble understanding which thread's information to dig into, in a crash log I got from iTunes.

It says that Thread 16 crashed. So, do I have to examine the code inside [FreePlayMenuScene dealloc] or is there a chance that the cause is located in another thread? For example, in Thread 0 there is a mention to NSDateFormatter, which I can't understand if is relevant or not.

To ask this as a generic question, when reading crash logs, should we only examine the thread that crashed or there may be helpful information in other threads as well? Unfortunately, I couldn't find a similar question here or anywhere online.

Here's the code:

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

Thanks a lot.

Well, never say never: there's always going to be a case where one thread does something that causes another thread to throw an exception and crash. However, when that happens you usually have some kind of timing problem or race condition, and it would be rare that the troublemaking thread was always in the same place when the crash occurs. In those situations, the bad thread "sets a trap" and then the crashing thread gets caught in it.

In your case, I don't think the date formatting has anything to do with it, unless you were sharing an NSDateFormatter on multiple threads (don't, it's not thread-safe).

Since the exception is EXC_BAD_ACCESS (access an invalid memory address) and it is happening in [CCScheduler unscheduleAllSelectorsForTarget:], my guess is that a bad pointer is lurking somewhere in your Cocos2D scene graph. Maybe you added a node that got overreleased? Hard to say. In this case, it's not necessarily another thread that is at fault, but it looks like the problem was set up by some other piece of code, which cause a problem when this code stumbled onto it.