Crash at _dispatch_client_callout + 28, no my code on stack trace

Question

Created Jul ’23

Replies 4

Boosts 0

Views 1.5k

Participants 2

I had 2 crash report from our customer. Both crash point is same but there is no my code on crash stack trace. How to fix this kind of crash problem.

Thread 1 Crashed::  Dispatch queue: com.apple.root.background-qos
0   libsystem_kernel.dylib 0x7ff81b84922a __pthread_kill + 10
1   libsystem_pthread.dylib 0x7ff81b880f7b pthread_kill + 263
2   libsystem_c.dylib 0x7ff81b7caca5 abort + 123
3   libc++abi.dylib 0x7ff81b83b082 abort_message + 241
4   libc++abi.dylib 0x7ff81b82c23d demangling_terminate_handler() + 266
5   libobjc.A.dylib 0x7ff81b529023 _objc_terminate() + 96
6   libc++abi.dylib 0x7ff81b83a4a5 std::__terminate(void (*)()) + 8
7   libc++abi.dylib 0x7ff81b83a456 std::terminate() + 54
8   libdispatch.dylib 0x7ff81b701a58 _dispatch_client_callout + 28
9   libdispatch.dylib 0x7ff81b704500 _dispatch_continuation_pop + 463
10  libdispatch.dylib 0x7ff81b715dff _dispatch_source_invoke + 2184
11  libdispatch.dylib 0x7ff81b7116a2 _dispatch_root_queue_drain + 343
12  libdispatch.dylib 0x7ff81b711e4d _dispatch_worker_thread2 + 160
13  libsystem_pthread.dylib 0x7ff81b87dc9d _pthread_wqthread + 256
14  libsystem_pthread.dylib 0x7ff81b87cc67 start_wqthread + 15

This crash point is exactly same with this post. I do not throw C++ exception.

https://developer.apple.com/forums/thread/725197

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’23

Both crash point is same but there is no my code on crash stack trace.

Please post a full crash report for this. See Posting a Crash Report for advice on how to do that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

Himadeus OP

Jul ’23

I have two crash reports. I renamed company name to "Example".

cr0.txt

cr1.txt

0

Answer 3

DTS Engineer OP

Apple

Jul ’23

Both of those crash reports look like the same issue, so I’m going to focus on the first one.

Consider this:

Exception Type:        EXC_CRASH (SIGABRT)

Your app has crashed because someone called abort. The most common cause is a language exception, and this seems to confirm that:

Application Specific Backtrace 0:
0  CoreFoundation          … __exceptionPreprocess + 242
1  libobjc.A.dylib         … objc_exception_throw + 48
2  AppKit                  … -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3845
3  AppKit                  … -[NSButtonCell performClick:] + 801
4  Example Application     … -[ViewController startRTSP] + 442
5  libdispatch.dylib       … _dispatch_client_callout + 8
6  libdispatch.dylib       … _dispatch_continuation_pop + 463
7  libdispatch.dylib       … _dispatch_source_invoke + 2184
8  libdispatch.dylib       … _dispatch_root_queue_drain + 343
9  libdispatch.dylib       … _dispatch_worker_thread2 + 160
10 libsystem_pthread.dylib … _pthread_wqthread + 256
11 libsystem_pthread.dylib … start_wqthread + 15

Your code in frame 4 has called AppKit in frames 3 and 2 which has thrown a language exception in frame 1. So the question is: Why has AppKit done that?

You’ll find the answer further up the stack. Frames 11 through 5 are characteristic of a Dispatch worker thread. And that’s confirmed by this:

Crashed Thread:        1  Dispatch queue: com.apple.root.background-qos

In short, you’re calling NSButton from a secondary thread. That’s not supported and, in this specific case, AppKit detected the problem and crashed.

Look at the code in frame 4 to work out why it’s doing this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

Himadeus OP

Jul ’23

I found non UI thread calling NSWindow.performMiniaturize().

I put dispatch_async(dispatch_get_main_queue(), ^{}) around UI method.

Thanks

0