Geek Answers Handbook

Crash in libdispatch _dispatch_semaphore_wait_slow

I sometimes encounter a crash inside libdispatch with the following backtrace resulting from the SecItemCopyMatching function.

 * 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

This crash seems completely random; it never happens to my colleagues. This mainly happens in a 32-bit iOS simulator, but it also happened once on the device.

I looked at the libdispatch source code and I can see that a crash can happen: _dispatch_semaphore_wait_slow() DISPATCH_SEMAPHORE_VERIFY_KR DISPATCH_CRASH _dispatch_hardware_crash() __builtin_trap() , but I really don't understand this.

Does anyone know what is going on?

Edit : The same crash also occurred while executing unit tests with the following backtrace:

 * 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
+6
source share
1 answer

When hitting this type of statement on x86_64, the rax logger contains an error code returned from the syscall kernel.

You can check this value from the debugger console using reg read . Detaching the debugger from the process after catching the exception should also generate crashreport (which you might want a file ).

Unfortunately, I don't think the rax trick works on i386, so you might need to return the return value to syscall through the breakpoint before clicking on this statement.

In this case, syscall is semaphore_wait , and the error will most likely be 0xf, i.e. KERN_INVALID_NAME (cf / usr / include / mach / kern_return.h)

Clicking this error is a sign of one of the following (in order of likelihood):

  • over-release / user after release of the send semaphore object
  • heap memory corruption
  • Incorrect port management in progress
+3
source

More articles:


All Articles