You’re now watching this thread. If you’ve opted in to email or web notifications, you’ll be notified when there’s activity. Click again to stop watching or visit your profile to manage watched threads and notifications.
You’ve stopped watching this thread and will no longer receive emails or web notifications when there’s activity. Click again to start watching.
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)?
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.
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:
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 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.
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"
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.
