未知的exception和崩溃
当我尝试快速滚动tableview或从远程重新加载数据时，我的应用程序崩溃。 一切似乎工作正常，当我让远程抓取发生，然后滚动tableview。 我不知道下面的崩溃日志意味着什么。 它有时工作正常，有时崩溃。
Incident Identifier: 710A120C-97E3-45C8-A7B2-E6A7BD98BC1A CrashReporter Key: 8bd54d8428128b9e6b8c04d59b86c40cccf33457 Hardware Model: iPhone5,2 Process: MyApp [5294] Path: /var/mobile/Applications/B6ED5B19-B8D7-4146-90A2-F709AE35292F/MyApp.app/MyApp Identifier: MyApp Version: ??? (???) Code Type: ARM (Native) Parent Process: launchd [1] Date/Time: 2013-02-26 16:45:27.693 +0200 OS Version: iOS 6.1.2 (10B146) Report Version: 104 Exception Type: EXC_CRASH (SIGSEGV) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 1 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0: 0 libobjc.A.dylib 0x3c3f658a _cache_getImp + 10 1 libobjc.A.dylib 0x3c3f6fa0 lookUpMethod + 24 2 libobjc.A.dylib 0x3c3f81e2 class_respondsToSelector + 26 3 CoreFoundation 0x3470a750 objectIsKindOfClass + 32 4 CoreFoundation 0x3470a49c __handleUncaughtException + 64 5 libobjc.A.dylib 0x3c3fba46 _objc_terminate() + 126 6 libc++abi.dylib 0x3be48118 safe_handler_caller(void (*)()) + 76 7 libc++abi.dylib 0x3be481b0 std::terminate() + 16 8 libc++abi.dylib 0x3be49626 __cxa_rethrow + 90 9 libobjc.A.dylib 0x3c3fb9b0 objc_exception_rethrow + 8 10 CoreFoundation 0x3465129c CFRunLoopRunSpecific + 452 11 CoreFoundation 0x346510c4 CFRunLoopRunInMode + 100 12 GraphicsServices 0x3822f336 GSEventRunModal + 70 13 UIKit 0x3656d2b4 UIApplicationMain + 1116 14 MyApp 0x000910a2 0x44000 + 315554 15 MyApp 0x0004668c 0x44000 + 9868 Thread 1 name: Dispatch queue: com.apple.libdispatch-manager Thread 1 Crashed: 0 libsystem_kernel.dylib 0x3c8df5d0 kevent64 + 24 1 libdispatch.dylib 0x3c81ad22 _dispatch_mgr_invoke + 806 2 libdispatch.dylib 0x3c816374 _dispatch_mgr_thread + 32 Thread 2 name: WebThread Thread 2: 0 libsystem_kernel.dylib 0x3c8dee30 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x3c8defd0 mach_msg + 48 2 CoreFoundation 0x346df2b6 __CFRunLoopServiceMachPort + 126 3 CoreFoundation 0x346de02c __CFRunLoopRun + 900 4 CoreFoundation 0x34651238 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x346510c4 CFRunLoopRunInMode + 100 6 WebCore 0x3a650390 RunWebThread(void*) + 440 7 libsystem_c.dylib 0x3c8480de _pthread_start + 306 8 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 3 name: com.apple.NSURLConnectionLoader Thread 3: 0 libsystem_kernel.dylib 0x3c8dee30 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x3c8defd0 mach_msg + 48 2 CoreFoundation 0x346df2b6 __CFRunLoopServiceMachPort + 126 3 CoreFoundation 0x346de02c __CFRunLoopRun + 900 4 CoreFoundation 0x34651238 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x346510c4 CFRunLoopRunInMode + 100 6 Foundation 0x34f9e888 +[NSURLConnection(Loader) _resourceLoadLoop:] + 304 7 Foundation 0x3502222c __NSThread__main__ + 968 8 libsystem_c.dylib 0x3c8480de _pthread_start + 306 9 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 4: 0 libsystem_kernel.dylib 0x3c8efd98 __workq_kernreturn + 8 1 libsystem_c.dylib 0x3c83dad6 _pthread_workq_return + 14 2 libsystem_c.dylib 0x3c83d7f2 _pthread_wqthread + 362 3 libsystem_c.dylib 0x3c83d680 start_wqthread + 4 Thread 5: 0 libsystem_kernel.dylib 0x3c8dee30 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x3c8defd0 mach_msg + 48 2 CoreFoundation 0x346df2b6 __CFRunLoopServiceMachPort + 126 3 CoreFoundation 0x346de02c __CFRunLoopRun + 900 4 CoreFoundation 0x34651238 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x346510c4 CFRunLoopRunInMode + 100 6 Foundation 0x34f755be -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 250 7 Foundation 0x35018c40 -[NSRunLoop(NSRunLoop) run] + 76 8 MyApp 0x0016b900 0x44000 + 1210624 9 Foundation 0x3502222c __NSThread__main__ + 968 10 libsystem_c.dylib 0x3c8480de _pthread_start + 306 11 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 6: 0 libsystem_kernel.dylib 0x3c8dee30 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x3c8defd0 mach_msg + 48 2 CoreFoundation 0x346df2b6 __CFRunLoopServiceMachPort + 126 3 CoreFoundation 0x346de02c __CFRunLoopRun + 900 4 CoreFoundation 0x34651238 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x346510c4 CFRunLoopRunInMode + 100 6 Foundation 0x34f755be -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 250 7 Foundation 0x35018c40 -[NSRunLoop(NSRunLoop) run] + 76 8 MyApp 0x000e63d0 0x44000 + 664528 9 Foundation 0x3502222c __NSThread__main__ + 968 10 libsystem_c.dylib 0x3c8480de _pthread_start + 306 11 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 7 name: com.apple.CFSocket.private Thread 7: 0 libsystem_kernel.dylib 0x3c8ef594 __select + 20 1 CoreFoundation 0x346e3474 __CFSocketManager + 676 2 libsystem_c.dylib 0x3c8480de _pthread_start + 306 3 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 8: 0 libsystem_kernel.dylib 0x3c8dee30 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x3c8defd0 mach_msg + 48 2 CoreFoundation 0x346df2b6 __CFRunLoopServiceMachPort + 126 3 CoreFoundation 0x346de02c __CFRunLoopRun + 900 4 CoreFoundation 0x34651238 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x346afc46 CFRunLoopRun + 94 6 MyApp 0x00115d7e 0x44000 + 859518 7 Foundation 0x3502222c __NSThread__main__ + 968 8 libsystem_c.dylib 0x3c8480de _pthread_start + 306 9 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 9: 0 libsystem_kernel.dylib 0x3c8efd98 __workq_kernreturn + 8 1 libsystem_c.dylib 0x3c83dad6 _pthread_workq_return + 14 2 libsystem_c.dylib 0x3c83d7f2 _pthread_wqthread + 362 3 libsystem_c.dylib 0x3c83d680 start_wqthread + 4 Thread 10: 0 libsystem_kernel.dylib 0x3c8efd98 __workq_kernreturn + 8 1 libsystem_c.dylib 0x3c83dad6 _pthread_workq_return + 14 2 libsystem_c.dylib 0x3c83d7f2 _pthread_wqthread + 362 3 libsystem_c.dylib 0x3c83d680 start_wqthread + 4 Thread 11 name: JavaScriptCore::BlockFree Thread 11: 0 libsystem_kernel.dylib 0x3c8ef08c __psynch_cvwait + 24 1 libsystem_c.dylib 0x3c840afc _pthread_cond_wait + 644 2 libsystem_c.dylib 0x3c840870 pthread_cond_timedwait + 40 3 JavaScriptCore 0x38625df6 WTF::ThreadCondition::timedWait(WTF::Mutex&, double) + 102 4 JavaScriptCore 0x38738532 JSC::BlockAllocator::blockFreeingThreadMain() + 78 5 JavaScriptCore 0x3874b030 WTF::wtfThreadEntryPoint(void*) + 12 6 libsystem_c.dylib 0x3c8480de _pthread_start + 306 7 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 12 name: JavaScriptCore::Marking Thread 12: 0 libsystem_kernel.dylib 0x3c8ef08c __psynch_cvwait + 24 1 libsystem_c.dylib 0x3c840afc _pthread_cond_wait + 644 2 libsystem_c.dylib 0x3c84acf8 pthread_cond_wait + 36 3 JavaScriptCore 0x386cb6dc JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode) + 140 4 JavaScriptCore 0x386cb620 JSC::MarkStackThreadSharedData::markingThreadMain() + 140 5 JavaScriptCore 0x3874b030 WTF::wtfThreadEntryPoint(void*) + 12 6 libsystem_c.dylib 0x3c8480de _pthread_start + 306 7 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 13 name: WebCore: CFNetwork Loader Thread 13: 0 libsystem_kernel.dylib 0x3c8dee30 mach_msg_trap + 20 1 libsystem_kernel.dylib 0x3c8defd0 mach_msg + 48 2 CoreFoundation 0x346df2b6 __CFRunLoopServiceMachPort + 126 3 CoreFoundation 0x346de02c __CFRunLoopRun + 900 4 CoreFoundation 0x34651238 CFRunLoopRunSpecific + 352 5 CoreFoundation 0x346510c4 CFRunLoopRunInMode + 100 6 WebCore 0x3a6eaccc WebCore::runLoaderThread(void*) + 140 7 JavaScriptCore 0x3874b030 WTF::wtfThreadEntryPoint(void*) + 12 8 libsystem_c.dylib 0x3c8480de _pthread_start + 306 9 libsystem_c.dylib 0x3c847fa4 thread_start + 4 Thread 14: 0 libsystem_kernel.dylib 0x3c8efd98 __workq_kernreturn + 8 1 libsystem_c.dylib 0x3c83dad6 _pthread_workq_return + 14 2 libsystem_c.dylib 0x3c83d7f2 _pthread_wqthread + 362 3 libsystem_c.dylib 0x3c83d680 start_wqthread + 4 Thread 1 crashed with ARM Thread State (32-bit): r0: 0x00000004 r1: 0x00000000 r2: 0x00000000 r3: 0x0042c714 r4: 0x00000001 r5: 0x00000000 r6: 0x0042c744 r7: 0x0042c764 r8: 0x00000000 r9: 0x0042c6c8 r10: 0x3e3a2188 r11: 0x00000002 ip: 0x00000171 sp: 0x0042c6d0 lr: 0x3c81ad27 pc: 0x3c8df5d0 cpsr: 0x60000010 如果有人能向我解释这个崩溃日志可能涉及到什么以及我如何解决这个问题，我会非常高兴。 非常感谢所有愿意帮助别人的人。
在我看来，这是悬在指针，你发送消息。 正如MikeD所说的，如果可以帮助的话，在exception处使用断点。 但是，由于您获得了SIGSEGV而不是SIGABRT，因此它不是100％可靠的。 而exception抛出不是真正的崩溃的原因，只是一个边界效应。
编辑
好的：在你的日志崩溃中，它说libsystem_kernel.dylib已经在kevent调用中崩溃了。 这不会帮助你，因为这是私人的，不透明的，你可以100％肯定这个lib做得好。 这可能会出现，因为您已经（无意）使用了不应写入的空间内存。 像悬挂指针一样。 假设你已经把内存分配给了0x2000，并且你有一个指向这个内存的指针，如果你释放了内存，但仍然使用这个指向这个地址的指针，如果其他人（比如libsystem_kernel）使用它，并且你改变了一些相同的数据时间（因为你的悬挂指针）。 那么对方会使用数据损坏，并且会发生一些随机的行为。 这就是为什么如果你从字面上分析你的崩溃日志，你会做错误的说法。 因为libSystem的kevent是稳定的。
顺便说一句你有线程1坠毁，但看看线程0，它也试图提出一个例外，但它没有时间去做。 这也可能是由于数据损坏而发生的。
这就是为什么我build议你再次崩溃，并与此相比较。 如果崩溃日志是相同的，那么我是完全错误的。 如果崩溃日志不同，这是一个悬挂指针。