gpt4 book ai didi

libdispatch _dispatch_semaphore_wait_slow 中的崩溃

转载 作者:行者123 更新时间:2023-12-03 15:23:51 27 4
gpt4 key购买 nike

我有时会在 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()__builtin_trap()但我真的不明白为什么会这样。

有谁知道发生了什么?

编辑 :使用以下回溯运行单元测试时也发生了同样的崩溃:
* thread #1: tid = 0x544131, 0x0375a830 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: 0x0375a830 libdispatch.dylib`_dispatch_semaphore_wait_slow + 278
frame #1: 0x0375a711 libdispatch.dylib`dispatch_semaphore_wait + 37
frame #2: 0x0392fb54 libxpc.dylib`xpc_connection_send_message_with_reply_sync + 231
frame #3: 0x0153c20a SystemConfiguration`__SCNetworkReachabilityServer_targetStatus + 234
frame #4: 0x015143ce SystemConfiguration`__SCNetworkReachabilityGetFlags + 415
frame #5: 0x015122a0 SystemConfiguration`reachPerform + 305
frame #6: 0x0344583f CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
frame #7: 0x03445295 CoreFoundation`__CFRunLoopDoSources0 + 437
frame #8: 0x0346229e CoreFoundation`__CFRunLoopRun + 910
frame #9: 0x03461ac3 CoreFoundation`CFRunLoopRunSpecific + 467
frame #10: 0x034618db CoreFoundation`CFRunLoopRunInMode + 123
frame #11: 0x050b79e2 GraphicsServices`GSEventRunModal + 192
frame #12: 0x050b7809 GraphicsServices`GSEventRun + 104
frame #13: 0x01591d3b UIKit`UIApplicationMain + 1225
frame #14: 0x000030ea Test Host`main(argc=10, argv=0xbfffeae0) + 138 at main.m:15

最佳答案

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

您应该能够通过 reg read 从调试器控制台检查该值。 .在遇到异常后从进程中分离调试器也应该生成一个崩溃报告(你可能想要 file)。

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

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

命中该错误表示以下情况之一(按可能性排序):

  • 调度信号量对象的过度释放/用户释放后
  • 堆内存损坏
  • 进程中的mach端口管理不善
  • 关于libdispatch _dispatch_semaphore_wait_slow 中的崩溃,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/21333757/

    27 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com