我们的应用程序似乎半随机地挂在 psynch_mutexwait 处。
它似乎与更新 CoreData 中存储的一堆数据的后台进程有关 - 但我完全无法弄清楚是谁锁定了导致死锁的原因。
以下是 lldb 给我的完整堆栈跟踪 - 这显然是不完整的，并且线程 1 的最后一帧是伪造的。在此之前的几行中，我在该方法中有一个断点，但从未被击中。
有没有什么方法可以知道正在等待什么锁？ （或者甚至获得正确的堆栈跟踪？）当然，涉及大量代码，这使得随机 NSLog 语句成为一项艰巨的任务。
(lldb) bt all
* thread #1: tid = 0x2503, 0x39da20fc libsystem_kernel.dylib`__psynch_mutexwait + 24, stop reason = signal SIGSTOP
frame #0: 0x39da20fc libsystem_kernel.dylib`__psynch_mutexwait + 24
frame #1: 0x39ceb128 libsystem_c.dylib`pthread_mutex_lock + 392
frame #2: 0x00022068 OnDeck`-[AttendanceWorkoutsController buildTable](self=0x00000003, _cmd=0x00000000) + 508 at AttendanceWorkoutsController.m:100
thread #2: tid = 0x2803, 0x39d92648 libsystem_kernel.dylib`kevent64 + 24
frame #0: 0x39d92648 libsystem_kernel.dylib`kevent64 + 24
frame #1: 0x39ccb4f0 libdispatch.dylib`_dispatch_mgr_invoke + 796
thread #5: tid = 0x2b03, 0x39d91eb4 libsystem_kernel.dylib`mach_msg_trap + 20
frame #0: 0x39d91eb4 libsystem_kernel.dylib`mach_msg_trap + 20
frame #1: 0x39d9204c libsystem_kernel.dylib`mach_msg + 40
thread #6: tid = 0x242f, 0x39d91eb4 libsystem_kernel.dylib`mach_msg_trap + 20
frame #0: 0x39d91eb4 libsystem_kernel.dylib`mach_msg_trap + 20
frame #1: 0x39d9204c libsystem_kernel.dylib`mach_msg + 40
thread #7: tid = 0x2c03, 0x39da2594 libsystem_kernel.dylib`select$DARWIN_EXTSN + 20
frame #0: 0x39da2594 libsystem_kernel.dylib`select$DARWIN_EXTSN + 20
frame #1: 0x31bff1f6 CoreFoundation`__CFSocketManager + 678
thread #8: tid = 0x2d03, 0x39da2d98 libsystem_kernel.dylib`__workq_kernreturn + 8
frame #0: 0x39da2d98 libsystem_kernel.dylib`__workq_kernreturn + 8
frame #1: 0x39cf0cfa libsystem_c.dylib`_pthread_workq_return + 18
(lldb)
通过让几个人查看代码，并追踪漫长而复杂的代码路径，我们找到了罪魁祸首。
在后台线程中运行的一种方法是查找并使用一些核心数据对象以及使用主线程上下文。
如果 IOS 能够提供有用的堆栈跟踪，那么肯定会有很大帮助。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
