Help in interpreting crash reports


I have received 3 almost identical crash reports from the App Store. They all come from the same user, and they are spaced just ± 45 seconds apart.

This is the backtrace of the crashed thread:

Crashed Thread:        3

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   Ssssssss [46033]

Thread 3 Crashed:
0   libsystem_kernel.dylib        	0x00007ff81b90f196 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007ff81b946ee6 pthread_kill + 263 (pthread.c:1670)
2   libsystem_c.dylib             	0x00007ff81b86dbdf __abort + 139 (abort.c:155)
3   libsystem_c.dylib             	0x00007ff81b86db54 abort + 138 (abort.c:126)
4   libc++abi.dylib               	0x00007ff81b901282 abort_message + 241
5   libc++abi.dylib               	0x00007ff81b8f33fb demangling_terminate_handler() + 267
6   libobjc.A.dylib               	0x00007ff81b5c67ca _objc_terminate() + 96 (
7   libc++abi.dylib               	0x00007ff81b9006db std::__terminate(void (*)()) + 6
8   libc++abi.dylib               	0x00007ff81b900696 std::terminate() + 54
9   libdispatch.dylib             	0x00007ff81b7a6047 _dispatch_client_callout + 28 (object.m:563)
10  libdispatch.dylib             	0x00007ff81b7a87c4 _dispatch_queue_override_invoke + 800 (queue.c:4882)
11  libdispatch.dylib             	0x00007ff81b7b5fa2 _dispatch_root_queue_drain + 343 (queue.c:7051)
12  libdispatch.dylib             	0x00007ff81b7b6768 _dispatch_worker_thread2 + 170 (queue.c:7119)
13  libsystem_pthread.dylib       	0x00007ff81b943c0f _pthread_wqthread + 257 (pthread.c:2631)
14  libsystem_pthread.dylib       	0x00007ff81b942bbf start_wqthread + 15 (:-1)

In the backtrace of the main thread, I can see that the error is caught by the app delegate which tries to display an alert, but obviously the message has no time to appear. Incidentally (but it's not my main question), I would like to know if it would be possible in such a case to block the background thread for the time the alert is displayed (e.g. using a dispatch queue)?

... (many other related lines)
72  SSUuuuIIIIIIIIIUUuuuu          	0x000000010e8089f2 +[NSAlert(Ssssssss) fatalError:] + 32
73  Ssssssss                      	0x000000010dd5e75b __universalExceptionHandler_block_invoke (in Ssssssss) (SQAppDelegate.m:421) + 333659
74  libdispatch.dylib             	0x00007ff81b7a4d91 _dispatch_call_block_and_release + 12 (init.c:1518)
75  libdispatch.dylib             	0x00007ff81b7a6033 _dispatch_client_callout + 8 (object.m:560)
76  libdispatch.dylib             	0x00007ff81b7b2fcf _dispatch_main_queue_drain + 954 (queue.c:7794)
77  libdispatch.dylib             	0x00007ff81b7b2c07 _dispatch_main_queue_callback_4CF + 31 (queue.c:7954)
78  CoreFoundation                	0x00007ff81ba62195 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 (CFRunLoop.c:1780)
79  CoreFoundation                	0x00007ff81ba21ebf __CFRunLoopRun + 2452 (CFRunLoop.c:3147)
80  CoreFoundation                	0x00007ff81ba20ec1 CFRunLoopRunSpecific + 560 (CFRunLoop.c:3418)
81  HIToolbox                     	0x00007ff8254a5f3d RunCurrentEventLoopInMode + 292 (EventLoop.c:455)
82  HIToolbox                     	0x00007ff8254a5d4e ReceiveNextEventCommon + 657 (EventBlocking.c:384)
83  HIToolbox                     	0x00007ff8254a5aa8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (EventBlocking.c:171)
84  AppKit                        	0x00007ff81eabfb18 _DPSNextEvent + 858 (CGDPSReplacement.m:818)
85  AppKit                        	0x00007ff81eabe9c2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 (appEventRouting.m:407)
86  AppKit                        	0x00007ff81eab1037 -[NSApplication run] + 586 (NSApplication.m:3432)
87  AppKit                        	0x00007ff81ea85251 NSApplicationMain + 817 (NSApplication.m:9427)
88  dyld                          	0x00007ff81b5ec41f start + 1903 (dyldMain.cpp:1165)

In all 3 reports, another thread indicates that it is sending or receiving a MIDI data (it's exactly the same backtrace in the 3 reports):

Thread 1:
0   libsystem_kernel.dylib        	0x00007ff81b908552 mach_msg2_trap + 10
1   libsystem_kernel.dylib        	0x00007ff81b9166cd mach_msg2_internal + 78 (mach_msg.c:201)
2   libsystem_kernel.dylib        	0x00007ff81b90f584 mach_msg_overwrite + 692 (mach_msg.c:0)
3   libsystem_kernel.dylib        	0x00007ff81b90883a mach_msg + 19 (mach_msg.c:323)
4   CoreMIDI                      	0x00007ff834adfd50 XServerMachPort::ReceiveMessage(int&, void*, int&) + 94 (XMachPort.cpp:62)
5   CoreMIDI                      	0x00007ff834b118c5 MIDIProcess::MIDIInPortThread::Run() + 105 (MIDIClientLib.cpp:204)
6   CoreMIDI                      	0x00007ff834af9c44 CADeprecated::XThread::RunHelper(void*) + 10 (XThread.cpp:21)
7   CoreMIDI                      	0x00007ff834afae9f CADeprecated::CAPThread::Entry(CADeprecated::CAPThread*) + 77 (CAPThread.cpp:324)
8   libsystem_pthread.dylib       	0x00007ff81b9471d3 _pthread_start + 125 (pthread.c:893)
9   libsystem_pthread.dylib       	0x00007ff81b942bd3 thread_start + 15 (:-1)
  • I wonder if this MIDI activity may be related to the crash, even if it doesn't occur in the crashed thread.
  • I also wonder if the dispatch block starting the backtrace of the thread 3 is the same that leads to the thread 1 (to open the NSAlert), which would mean that it's after the error, or if it's a dispatch block into which the error occurs.
  • Finally,

I wonder if std::terminate() could indicate a problem in C++ codes because I have some part of the application written in C++, and it would be a clue.

More generally, is it something in these backtraces that can help me to find what's the problem ?

Any help greatly appreciated, thanks!



You post confused me because you’re talking about two crash reports but only posted one of them. So I was looking for NSAlert code in your crash report, which isn’t there )-:

Anyway, with reference to the crash report you posted, the backtrace looks like this:

Thread 3 Crashed:
0   libsystem_kernel.dylib   … __pthread_kill + 10
1   libsystem_pthread.dylib  … pthread_kill + 263 (pthread.c:1670)
2   libsystem_c.dylib        … __abort + 139 (abort.c:155)
3   libsystem_c.dylib        … abort + 138 (abort.c:126)
4   libc++abi.dylib          … abort_message + 241
5   libc++abi.dylib          … demangling_terminate_handler() + 267
6   libobjc.A.dylib          … _objc_terminate() + 96 (
7   libc++abi.dylib          … std::__terminate(void (*)()) + 6
8   libc++abi.dylib          … std::terminate() + 54
9   libdispatch.dylib        … _dispatch_client_callout + 28 (object.m:563)
10  libdispatch.dylib        … _dispatch_queue_override_invoke + 800 (queue.c:4882)
11  libdispatch.dylib        … _dispatch_root_queue_drain + 343 (queue.c:7051)
12  libdispatch.dylib        … _dispatch_worker_thread2 + 170 (queue.c:7119)
13  libsystem_pthread.dylib  … _pthread_wqthread + 257 (pthread.c:2631)
14  libsystem_pthread.dylib  … start_wqthread + 15 (:-1)

Frames 14 through 9 are Dispatch queue infrastructure. Frame 8 indicates that something has gone wrong at the C++ layer which has resulted in a call to std::terminate(). That’s very likely to be an unhandled C++ language exception [1] coming from your code. It’s not coming from Dispatch, because Dispatch doesn’t use C++, and it’s rare [2] for Apple framework code to throw C++ exceptions.

You might expect your code to show up in the thread 3 backtrace but I suspect that the compiler has applied a tail call optimisation which prevents it from showing up.

Tracking down bugs like this is hard.

Coming back to the NSAlert crash described in your post, in frame 73 there’s a symbol __universalExceptionHandler_block_invoke. Is that your code?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + ""

[1] If it were an unhandled Objective-C language exception, there’d be a Last Exception Backtrace section in the crash report.

[2] Apple code shouldn’t be doing that, but it’s not like that never happens (-:

I wasn't able to post my answer because of the 'This post contains sensitive language. Please revise it in order to continue.' error... What can I do?

Thanks for your help.

I really don't understand what happened with the uploaded report. Many lines are missing from the main thread, but the version I have here is complete. I probably made a mistake somewhere, sorry for that. I join the file again.

universalExceptionHandler is a C function I call in my app delegate to catch errors from both Signals and NSExceptions. From there, I try to save a recovered file and open a NSAlert. When required, I use a dispatch block to open the alert in the main thread. But in practice, the alert seems only useful for exceptions while it fails with signals (at least some of them, I'm not sure about that...).

About C++, something is weird: all C++ codes used by this software are related to audio units and make an extensive use of Core Audio. However, I don't see any reference to Core Audio in the binary image. I cannot figure out how it is possible... Could it mean that something went wrong during the launch of the application? Or that Core Audio was crashed for some reason?

  • The issue 'This post contains sensitive language' seems related to the crash report I tried to join to my reply, it's why I finally post it without it. I tried to put the report alone in another post, but it doesn't work. I finally sent it to you by email.

Add a Comment

Regarding the problems you’re having posting your crash report, I’d appreciate you joining me over on this thread where I’m trying to work out exactly what’s causing this.

The standard workaround is to post the crash report to a file hosting service and then post the URL here. Make sure to post that URL in the ‘clear’. See tip 14 in the (always ironically named) Quinn’s Top Ten DevForums Tips.


I finally sent it to you by email.

That works to (-:

universalExceptionHandler is a C function I call in my app delegate to catch errors from both Signals and NSExceptions.

Oi vey! That’s so unsafe. Both signals and Objective-C language exceptions leave your process is an undefined state. It’s not safe to do anything even remotely this complex in that environment. Moreover, doing so is likely to disrupt the Apple crash reporter, thus preventing it from generating the crash reports you need to uncover the original issue.

I talk about this in gory detail in Implementing Your Own Crash Reporter.

Now, C++ is a special case here because the Apple crash reporter doesn’t display the source of C++ exceptions [1]. If your app makes heavy use of C++ then it might be sensible to add ‘last ditch’ exception handlers to try to track down any rogue C++ exceptions.

IMPORTANT Don’t try to recover from that. Just log whatever info you need to identify the crash and then crash your process. While it’s possible to catch C++ exceptions and continue running, it’s not safe to do so if the exception has crossed a C, Objective-C, or Swift boundary.

As to what you should do right now, that kinda depends on whether you’re in touch with the customer who’s having this problem?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + ""

[1] See this thread for details.

Many thanks to the very helpful link! Even if I don't try to implement my own crash reporter, this post contains a lot of useful info. After reading, it seems to me that there is no real benefit in this case to catch signals, or even C++ exceptions. Either to save the application state or to display an alert, I need Objective-C and there is nothing I can do with just C or C++ codes, except printing something in the console. But it wouldn't be helpful here since I'm not in touch with the users whose I receive crash reports via the Xcode Organizer.

What you tell about NSException is surprising to me: from my experience, saving a 'recoverable' session and displaying an alert during an exception handling works correctly. The fact that the file could be corrupted in some cases is handled during loading anyway so, theoretically, it cannot lead to a second crash (the file is just discarded if it's corrupted) .

To terminate the process after the handler, I don't call exit, but I uninstall my handlers and then raise the exception again (or create one for a signal). Probably not the most elegant way, but I remember doing so because the application didn't quit otherwise (I should try again just returning as you recommend).

Finally, it would be nice to know what's going on with Core Audio. I see only two possible scenarios: 1) Core Audio is available but the report lacks some lines in the binary image section 2) Core Audio is unavailable for some reason I cannot imagine... Knowing that could be useful to continue investigating.