Crittercism Reports on main.m

Question

简短说明： 我们在main.m中有一个SIGABRT崩溃。我们得到的唯一信息是来自Crittercism的最小崩溃报告，我们不知道如何重现崩溃。

详细描述： 除上述以外。我们最初的理论是，用户从核心数据进程崩溃，但在堆栈跟踪中没有提到这一点。我们认为，当用户尝试再次运行应用程序时，由于数据损坏而无法加载。我们没有启动我们的任何代码，所以我们怎么能在这样一个真正的阶段崩溃。我们有几个不同的应用程序版本有这个问题，没有添加或删除特定的库，所以它不应该是由于任何损坏的文件。

我们不确定这里是否有明确的答案，因为这个问题对于我们所拥有的信息来说非常复杂，但是如果任何人至少可以建议任何调查和分析的线索 - 那太棒了。线程

Crashed Thread 

libsystem_kernel.dylib 0x387fb350 __pthread_kill + 8 + 8  
libsystem_c.dylib 0x35ada973 abort + 95 + 94  
libc++abi.dylib 0x3307cd4f abort_message + 75 + 74 
libc++abi.dylib 0x33079ff9 _ZL17default_terminatev + 25 + 24  
libobjc.A.dylib 0x326c9a77 _ZL15_objc_terminatev + 147 + 146  
libc++abi.dylib 0x3307a07b _ZL19safe_handler_callerPFvvE + 79 + 78 
libc++abi.dylib 0x3307a114 _ZSt9terminatev + 20 + 19  
libc++abi.dylib 0x3307b599 __cxa_current_exception_type + 1 
libobjc.A.dylib 0x326c99d1 objc_exception_rethrow + 13 + 12 
CoreFoundation 0x38328f21 CFRunLoopRunSpecific + 457 + 456 
CoreFoundation 0x38328d49 CFRunLoopRunInMode + 105 + 104  
UIKit 0x39af947d -[UIApplication _run] + 669 + 668 
UIKit 0x39af62f9 UIApplicationMain + 1121 + 1120  
DM 0x0010e41b main (main.m:14) 

休息（可以了解更多信息有用）

Thread: Unknown Name 
libsystem_kernel.dylib 0x387eb648 kevent64 + 24 + 24  
libdispatch.dylib 0x3a048658 _dispatch_mgr_thread$VARIANT$mp + 36 + 35 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8 
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8 
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387eaeb4 mach_msg_trap + 20 + 20 
CoreFoundation 0x383b7045 __CFRunLoopServiceMachPort + 129 + 128 
CoreFoundation 0x383b5da3 __CFRunLoopRun + 883 + 882 
CoreFoundation 0x38328ebd CFRunLoopRunSpecific + 357 + 356 
CoreFoundation 0x38328d49 CFRunLoopRunInMode + 105 + 104 
WebCore 0x3a3a9a45 _ZL12RunWebThreadPv + 445 + 444 
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387eaeb4 mach_msg_trap + 20 + 20 
CoreFoundation 0x383b7045 __CFRunLoopServiceMachPort + 129 + 128 
CoreFoundation 0x383b5da3 __CFRunLoopRun + 883 + 882 
CoreFoundation 0x38328ebd CFRunLoopRunSpecific + 357 + 356 
CoreFoundation 0x38328d49 CFRunLoopRunInMode + 105 + 104 
Foundation 0x327edbcd +[NSURLConnection(Loader) _resourceLoadLoop:] + 309 + 308 
Foundation 0x3287167d __NSThread__main__ + 973 + 972 
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387eaf1c semaphore_timedwait_trap + 8 + 8 
CoreLocation 0x33ff06e9 _Z22CLClientInvokeCallbackP10__CLClient13CLClientEventP11objc_object + 345 + 344 
CoreLocation 0x33ff3d4d ___CLClientCreateConnection_block_invoke_0 + 389 + 388 
CoreLocation 0x3402a073 __setEventHandler_block_invoke_0 + 347 + 346 
libxpc.dylib 0x33f557e9 _xpc_connection_mach_event + 773 + 772 
libdispatch.dylib 0x3a049529 _dispatch_mach_msg_invoke$VARIANT$mp + 125 + 124 
libdispatch.dylib 0x3a045e91 _dispatch_queue_drain$VARIANT$mp + 81 + 80 
libdispatch.dylib 0x3a0497b7 _dispatch_mach_invoke$VARIANT$mp + 163 + 162 
libdispatch.dylib 0x3a045e91 _dispatch_queue_drain$VARIANT$mp + 81 + 80 
libdispatch.dylib 0x3a045dc1 _dispatch_queue_invoke$VARIANT$mp + 41 + 40 
libdispatch.dylib 0x3a045e91 _dispatch_queue_drain$VARIANT$mp + 81 + 80 
libdispatch.dylib 0x3a045dc1 _dispatch_queue_invoke$VARIANT$mp + 41 + 40 
libdispatch.dylib 0x3a04691d _dispatch_root_queue_drain + 185 + 184 
libdispatch.dylib 0x3a046ac1 _dispatch_worker_thread2 + 85 + 84 
libsystem_c.dylib 0x35a75a11 _pthread_wqthread + 361 + 360 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8 
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365 


Thread: Unknown Name 
libsystem_kernel.dylib 0x387eaeb4 mach_msg_trap + 20 + 20 
CoreFoundation 0x383b7045 __CFRunLoopServiceMachPort + 129 + 128 
CoreFoundation 0x383b5da3 __CFRunLoopRun + 883 + 882 
CoreFoundation 0x38328ebd CFRunLoopRunSpecific + 357 + 356 
CoreFoundation 0x383879bb CFRunLoopRun + 99 + 98 
DM 0x0024f947 +[ASIHTTPRequest runRequests] + 151 
Foundation 0x3287167d __NSThread__main__ + 973 + 972  
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387fb594 select$DARWIN_EXTSN + 20 + 20 
libsystem_c.dylib 0x35a80311 _pthread_start + 309 + 308 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8 
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365 

Thread: Unknown Name 
libsystem_kernel.dylib 0x387fbd98 __workq_kernreturn + 8 + 8 
libsystem_c.dylib 0x35a75a16 _pthread_wqthread + 366 + 365 

非常感谢您的宝贵时间 - 我们对此表示赞赏分配。

感谢， Justas

Answer 1

的崩溃是因为异常的，看objc_exception_rethrow在坠毁线程，这是主线程的堆栈跟踪。可悲的是Exception Backtrace和Exception Reason不可用。没有这个，你什么都做不了。这会告诉你你的代码在哪里引发异常，以及实际的异常是什么。

异常会被运行时重新引入到另一个runloop中，为了赶上它们，需要崩溃报告框架来支持这个。 Crittercism正在使用PLCrashReporter，它支持这一点。但是，也许你安装了旧版本的SDK，或者它们使用的是旧版本。

Answer 2

@Kerni，谢谢你的时间！

我们已经联系了Crittercism，并且他们建议我们查看面包屑 - 这将允许我们在应用程序中放置大量自定义调用（用户触发任何特定操作+其他重要的系统调用），一旦它应用程序将崩溃Crittercism将为我们存储99个最后的面包屑。这将使我们能够理解用户在这次特殊事故中的旅程。

此外，我们遇到了使用元数据直接与用户联系并与他们交流的能力。这也可以让我们获得关于特定问题的更多信息。最重要的是它可以让我们更有效地对崩溃做出反应。

我知道这不是我们问题的正确答案，但至少我们将有所有必需的工具在实施后获得答案。

谢谢