iOS App在线程0中崩溃

Question

One of our users confronted us with the problem, that the App crashes directly after the app start. Now we only got two Crash Reports, but couldn't reproduce the Crash on any of our devices. The Build is an Enterprise Distribution Build.

The Device is an iPhone 4, with iOS 6.

Any idea would be much appreciated.

Date/Time:       2012-10-30 17:41:11.762 +0100
OS Version:      iOS 6.0 (10A403)
Report Version:  104

Exception Type:  EXC_CRASH (SIGTRAP)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_c.dylib              0x38edad8e memmove$VARIANT$CortexA8 + 654
1   QuartzCore                     0x3401c81c CA::Render::Encoder::encode_bytes(void const*, unsigned long) + 24
2   QuartzCore                     0x3401d494 CA::Render::Layer::Ext::encode(CA::Render::Encoder*) const + 152
3   QuartzCore                     0x3401c706 CA::Render::encode_set_object(CA::Render::Encoder*, unsigned long, unsigned int, CA::Render::Object*, unsigned int) + 42
4   QuartzCore                     0x3401b3e2 CA::Context::commit_layer(CA::Layer*, unsigned int, unsigned int, void*) + 114
5   QuartzCore                     0x34011076 CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 310
6   QuartzCore                     0x3401101c CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 220
7   QuartzCore                     0x3401101c CA::Layer::commit_if_needed(CA::Transaction*, void (*)(CA::Layer*, unsigned int, unsigned int, void*), void*) + 220
8   QuartzCore                     0x3401052c CA::Context::commit_transaction(CA::Transaction*) + 1024
9   QuartzCore                     0x34010024 CA::Transaction::commit() + 312
10  QuartzCore                     0x3400fe84 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 56
11  CoreFoundation                 0x34e326ca __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 18
12  CoreFoundation                 0x34e309bc __CFRunLoopDoObservers + 272
13  CoreFoundation                 0x34e30d12 __CFRunLoopRun + 738
14  CoreFoundation                 0x34da3eb8 CFRunLoopRunSpecific + 352
15  CoreFoundation                 0x34da3d44 CFRunLoopRunInMode + 100
16  GraphicsServices               0x35b0c2e6 GSEventRunModal + 70
17  UIKit                          0x379e92fc UIApplicationMain + 1116
18  MyApp                           0x000ceb90 main (main.m:16)
19  MyApp                           0x000ceb2c start + 36

Here's the second one:

Date/Time:       2012-10-29 15:54:48.926 +0100
OS Version:      iOS 6.0 (10A403)
Report Version:  104

Exception Type:  EXC_CRASH (SIGTRAP)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib         0x33b1beb4 mach_msg_trap + 20
1   libsystem_kernel.dylib         0x33b1c048 mach_msg + 36
2   CoreFoundation                 0x34e32040 __CFRunLoopServiceMachPort + 124
3   CoreFoundation                 0x34e30d5a __CFRunLoopRun + 810
4   CoreFoundation                 0x34da3eb8 CFRunLoopRunSpecific + 352
5   CoreFoundation                 0x34da3d44 CFRunLoopRunInMode + 100
6   GraphicsServices               0x35b0c2e6 GSEventRunModal + 70
7   UIKit                          0x379e92fc UIApplicationMain + 1116
8   MyApp                           0x00024b90 main (main.m:16)
9   MyApp                           0x00024b2c start + 36

Answer 1

The first one I would suspect that you're animating things while they're being put onto the screen (since it happens during launch). Perhaps something UI-related you're doing in your application delegate, or otherwise doing from a view controller that isn't on the screen yet. That said, the Core Animation calls may be a red herring (see below).

The second one is unlikely the actual crash point. iOS cannot always determine which thread actually crashed, and sometimes will blame the wrong one (and most often thread 0 will be incorrectly blamed). Crashing in a _trap function is really unlikely. The thread is generally suspended at this point. I would study the other threads and see if one of them was doing something suspicious. If you find it elsewhere, then this could also be the cause of the first crash.