应用程序挂起在__psynch_mutexwait [英] App hangs at __psynch_mutexwait

问题描述

我们的应用程式似乎半挂在psynch_mutexwait。
它似乎与更新存储在CoreData中的一堆数据的后台进程相关 - 但我完全无法弄清楚谁锁定了导致死锁的原因。

Our app seems to semi-randomly hang at psynch_mutexwait. It seems to be related to a background process that updates a bunch of data stored in CoreData - but I've been completely unable to figure out just who is locking on what to cause the deadlock.

下面是lldb给我的完整的堆栈跟踪 - 这显然是不完整的，并且线程1的最后一帧是伪造的。我在那个方法中有一个断点，在那之前几行，它从来没有命中。

Following is the complete stack trace that lldb gives me - which is obviously incomplete, AND the last frame of Thread 1 is bogus. I had a breakpoint in that method a few lines before that, and it was never hit.

有什么方法可以找出什么锁等待？ （或者甚至得到正确的堆栈跟踪？）当然有代码的LOTS，这使随机NSLog语句是一个巨大的承诺。

Is there ANY way of figuring out what lock is being waited on? (or even get correct stack traces?) Of course there is LOTS of code involved, which makes random NSLog statements a massive undertaking.

(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) 

推荐答案

通过让几个人看代码，并通过复杂的代码路径，我们发现，是罪魁祸首。
在后台线程中运行的一个方法是查找和使用一些Core Data对象并使用主线程上下文。

By having several people look at the code, and trace through the long complicated code paths, we found what appears to have been the culprit. One method running in a background thread was finding and using some Core Data objects and using the main-threads context.

当然会帮助一个LOT if IOS将提供有用的堆栈跟踪。

Sure would have helped a LOT if IOS would give useful stack traces.

这篇关于应用程序挂起在__psynch_mutexwait的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！