libdispatch _dispatch_semaphore_wait_slow崩溃

时间:2014-01-24 13:18:30

标签: crash libdispatch

我有时会在libdispatch内部发生崩溃,其中包含来自SecItemCopyMatching函数的以下回溯。

* thread #1: tid = 0x169ee8, 0x0374c830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278, queue = 'com.apple.main-thread, stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0374c830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278
    frame #1: 0x0374c711 libdispatch.dylib`dispatch_semaphore_wait + 37
    frame #2: 0x03921b54 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 231
    frame #3: 0x01448e99 Security`securityd_message_with_reply_sync + 78
    frame #4: 0x01449098 Security`securityd_send_sync_and_do + 81
    frame #5: 0x01459926 Security`__SecItemCopyMatching_block_invoke + 218
    frame #6: 0x014589f9 Security`SecOSStatusWith + 37
    frame #7: 0x014597da Security`SecItemCopyMatching + 208
    frame #8: 0x0022b482 MyApp`+[BITKeychainUtils getPasswordForUsername:andServiceName:error:](self=0x00399e3c, _cmd=0x002d21e0, username=0x003a336c, serviceName=0x0c17c420, error=0xbfffeb24) + 738 at BITKeychainUtils.m:63
    frame #9: 0x00221eff MyApp`-[BITHockeyBaseManager stringValueFromKeychainForKey:](self=0x0c1b6400, _cmd=0x002d2322, key=0x003a336c) + 175 at BITHockeyBaseManager.m:297
    frame #10: 0x001ef2c2 MyApp`-[BITAuthenticator publicInstallationIdentifier](self=0x0c1b6400, _cmd=0x002d2678) + 194 at BITAuthenticator.m:749
    frame #11: 0x00228be1 MyApp`-[BITHockeyManager startManager](self=0x0c6a1e90, _cmd=0x002d2358) + 865 at BITHockeyManager.m:196
    frame #12: 0x00090ed4 MyApp`-[ApplicationDelegate init](self=0x0c1850e0, _cmd=0x0375f96b) + 212 at ApplicationDelegate.m:86
    frame #13: 0x01583cde UIKit`UIApplicationMain + 1132
    frame #14: 0x00002e32 MyApp`main(argc=1, argv=0xbfffee74) + 178 at main.m:15

这次崩溃似乎完全随机,我的同事从未发生过这种情况。它主要发生在32位iOS模拟器中,但也在设备上发生过一次。

我查看了libdispatch source code,我发现可能会发生崩溃:_dispatch_semaphore_wait_slow()DISPATCH_SEMAPHORE_VERIFY_KRDISPATCH_CRASH_dispatch_hardware_crash()→{{ 1}}但我真的不明白为什么会这样。

有谁知道发生了什么事?

编辑:使用以下回溯运行单元测试时也会发生同样的崩溃:

__builtin_trap()

1 个答案:

答案 0 :(得分:3)

在x86_64上遇到这种类型的断言时,rax寄存器包含从内核系统调用返回的错误代码。

您应该能够通过reg read从调试器控制台检查该值。在命中异常之后将调试器从进程中分离也应该生成一个crashreport(你可能想要file)。

不幸的是我认为rax技巧不适用于i386,所以你可能需要在点击断言之前通过断点检索系统调用返回值。

在这种情况下,系统调用是semaphore_wait,错误很可能是0xf,即KERN_INVALID_NAME(c.f。/usr/include/mach/kern_return.h)

点击该错误表示以下之一(按可能性顺序):

  • 发布信号量对象的过度释放/用户自由之后
  • 堆内存损坏
  • 马赫端口管理不善