Fatal signal EXC_BREAKPOINT / EXC_ARM_BREAKPOINT at _dispatch_queue_wakeup_with_qos_slow

Question

Created Aug ’15

Replies 3

Boosts 0

Views 2.4k

Participants 3

Getting lots of crashes due to Fatal signal EXC_BREAKPOINT / EXC_ARM_BREAKPOINT at _dispatch_queue_wakeup_with_qos_slow.

We have always been seeing a small number of these in iOS 8 with only system symbols in the stack trace. BaseBoard in particular seemed to be the main source.

However, in iOS 9 the volume has increased substantially and BaseBoard no longer seems to be the main culprit. Here is the stack from a crashing thread in iOS 9:

libdispatch.dylib    _dispatch_queue_wakeup_with_qos_slow+ 1008
libdispatch.dylib    _dispatch_queue_wakeup_with_qos_slow+ 36
libdispatch.dylib    _dispatch_barrier_sync_f_slow+ 1104
libsystem_network.dylib    tcp_connection_did_fallback+ 100
CFNetwork    SocketStream::copyProperty_NoLock(void const*, __CFString const*)+ 1796
CoreFoundation    CFReadStreamCopyProperty+ 156
CFNetwork    HTTPProtocol::handleStreamEvent(__CFHTTPMessage*, dispatch_data_s*, CFStreamError const*)+ 188
CFNetwork    ___ZN11SSPDYStream22_onqueue_invokeHandlerEv_block_invoke+ 44
libdispatch.dylib    _dispatch_client_callout+ 12
libdispatch.dylib    _dispatch_block_invoke+ 536
CFNetwork    RunloopBlockContext::_invoke_block(void const*, void*)+ 32
CoreFoundation    CFArrayApplyFunction+ 64
CFNetwork    RunloopBlockContext::perform()+ 132
CFNetwork    MultiplexerSource::perform()+ 308
CFNetwork    MultiplexerSource::_perform(void*)+ 64
CoreFoundation    __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+ 20
CoreFoundation    __CFRunLoopDoSources0+ 536
CoreFoundation    __CFRunLoopRun+ 720
CoreFoundation    CFRunLoopRunSpecific+ 380
CFNetwork    +[NSURLConnection(Loader) _resourceLoadLoop:]+ 408
Foundation    __NSThread__start__+ 996
libsystem_pthread.dylib    _pthread_body+ 152
libsystem_pthread.dylib    _pthread_start+ 152
libsystem_pthread.dylib    thread_start+

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’15

Getting lots of crashes due to Fatal signal
EXC_BREAKPOINT
/
EXC_ARM_BREAKPOINT
at
_dispatch_queue_wakeup_with_qos_slow
.

I’ve no idea what’s going here but I’d love to see a full crash log. Can you post one?

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 2

DTS Engineer OP

Apple

Aug ’15

[bran sent me his non-standard crash log via email.]

The crash log shows that the backtrace was from iOS 9.0b5. By pulling apart

_dispatch_queue_wakeup_with_qos_slow

on that release I was able to see that this is a dispatch ‘object resurrection’ crash caused by a call to

dispatch_retain

on the queue itself.

Two things to note here:

A crash like this would leave a really helpful breadcrumb in a standard crash log but, alas, that information was lost by the custom crash reporter that you’re using.
A standard crash report would allow me to check whether this is a common problem or not. Alas, custom crash reports make that hard.

At this point I’m out of suggestions for how to debug this further. It’s likely that this is a queue ‘use after free’ problem within CFNetwork (or the underlying “tcp_connection” subsystem) but it’s hard to be 100%.

I recommend you toss this into Radar; if you can figure out a way to reproduce the problem, that’d be ideal.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

1

Answer 3

chamberlin OP

Sep ’15

Did you ever figure this out, and/or submit to radar? I'm seeing the same problem, though I have only found crash reports for it in beta5, hoping that it was simply fixed in GM.

0