Help in interpreting crash reports

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 (objc-exception.mm:498)
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" + "@" + "apple.com"

[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?

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.

But:

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" + "@" + "apple.com"

[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.