The principle of cause and effect
Of course, I know that it’s extremely frustrating when an application crashes on you.
That’s why I tried to minimize the harm, done by a crash, in Übercaster as much as possible. Übercaster has a built-in autosave feature and it even recovers partial audio recordings after the application or the whole computer crashed. All editing is done in a non-destructive way (i.e. not changing the original audio).
As long as the computer didn’t explode, the hard disk didn’t melt and the project file is still there, Übercaster should be able to recover the project on the next launch and recover all audio recordings, even if it crashed in the middle of a recording session.
This doesn’t mean that Übercaster constantly crashes, is supposed to crash or that I tolerate crashing bugs! Not at all.
The thing is, that there’re a lot of wheels turning in Übercaster. And a lot of these wheels aren’t even part of Übercaster itself.
There’s a lot of external hardware involved: Microphones, Mixers, Audio In/Out boxes, you name it. Some of these come with their own drivers or firmeware. They can be unplugged (or plugged in) while Übercaster’s running or even during recording.
Then there are 3rd party products like Skype (connected via the Skype API framework), iChat or other applications, providing audio (or sometimes not providing it).
And of course there are 3rd party audio units, small (or not so small) audio plugins, running inside the host application (i.e. Übercaster) and processing audio. Or sometimes crashing…
In case of a crash, from the user’s point of view, Übercaster just crashes. The next thing they see is probably the Crash Reporter dialog from Apple, pointing it’s bony finger at Übercaster.
What the normal user doesn’t know: The crash reporter doesn’t really know what happened, or better: it doesn’t care. All it knows is that Übercaster was running and then something bad happend, resulting in Übercaster’s sudden death.
Sidenote: Unfortunately, Apple’s crash reporter doesn’t provide any way to send its reports to 3rd party developers. Thus, Übercaster contains its own crash reporter, which sends crash reports to our servers. Crash reports can help to fix bugs, but most of the time we need more information than just one single crash report. Therefor the Übercaster crash reporter contains a text field for comments. These comments are supposed to provide additional information on what happened before the crash or ideally a way to reproduce the problem.
The crash reporters comment field is not supposed to be used for support requests. Crash reports aren’t handled by our support system, the reports are collected separately and batch-reviewed frequently, but later. Please also don’t expect a reply to crash reports. However, providing your mail address in the crash reporter gives us a way to come back to you, if we need additional information and it also helps to categorize reports.
So please send the crash reports, but use our support mail address for support requests!
Last but not least, the crash reporter’s comment field is definitely not a good place for name calling. It doesn’t really help to solve the problem and rather kills the mood and our motivation.
Definitely not always, but quite sometimes, it turns out that the cause for a crash wasn’t Übercaster itself, but some code running inside Übercaster in form of a plugin, audio unit or framework.
For example, here’s a message I received from a Übercaster user:
I've bought Ubercaster a couple of months ago. [...] The problem is that the program always crashes. I really need some help !
Fortunately, the user also attached a crash report:
Process: Ubercaster [741] Thread 4 Crashed: 0 ??? 0000000000 0 + 0 1 com.celemony.melodynebridge.au 0x08070fc8 GNAudioUnitWrapperViewEntry + 463264 2 libSystem.B.dylib 0x942de6f5 _pthread_start + 321 3 libSystem.B.dylib 0x942de5b2 thread_start + 34
Yes, the problem is that the program always crashes. But it’s not Übercaster’s fault! Obviously, a 3rd party audio unit had some problems when loading into Übercaster.
The solution for this is relatively easy: throw away the faulty audio unit and/or contact the customer support of the audio unit.
Unfortunately it’s not always that easy to tell who’s really to blame. For example: The following backtrace was part of a Übercaster crash report:
CMCrashReporter: Application: Ubercaster App Version: 1128 Mac os: 10.6.2 ... Thread 10 Crashed: 0 libAudiointerposingLeo.dylib 0x002a2995 AudioController::writeToInputAudioFile(...) + 39 1 libAudiointerposingLeo.dylib 0x002a6965 SkypeCapAudioDeviceIOProc::ioProc(...) + 73 2 libAudiointerposingLeo.dylib 0x002a3a6b AudioDeviceIOProcInterpose::internalIoProc(...) + 163 3 libAudiointerposingLeo.dylib 0x002a78e1 AudioDeviceIOProcesPool::callRealIOProc(...) + 83 4 libAudiointerposingLeo.dylib 0x002a865c _AudioDeviceIOProcesPool_staticIoProc(...) + 68 5 com.apple.audio.CoreAudio 0x91ce15b4 HP_IOProc::Call(...) + 374 6 com.apple.audio.CoreAudio 0x91ce131a IOA_Device::CallIOProcs(...) + 370 7 com.apple.audio.CoreAudio 0x91ce1116 HP_IOThread::PerformIO(...) + 620 8 com.apple.audio.CoreAudio 0x91cde4fa HP_IOThread::WorkLoop() + 2506 9 com.apple.audio.CoreAudio 0x91cddb2b HP_IOThread::ThreadEntry(HP_IOThread*) + 17 10 com.apple.audio.CoreAudio 0x91cdda42 CAPThread::Entry(CAPThread*) + 140 11 libSystem.B.dylib 0x90be4fbd _pthread_start + 345 12 libSystem.B.dylib 0x90be4e42 thread_start + 34
Well, Übercaster crashed!
But wait, where’s Übercaster in this backtrace? Right: nowhere. The only thing, Übercaster did wrong in this case, was its kindness to play host for another process. Several paragraphs of crash reporter gibberish later, I found the following information:
Binary Images: 0x1000 - 0x1bdffb +com.pleasantsoftware.ubercaster v1.6.4 (1128) <..> /Applications/Ubercaster.app/Contents/MacOS/Ubercaster 0x2a1000 - 0x2b0fff +libAudiointerposingLeo.dylib ??? (???) <...> /Applications/SkypeCap/SkypeCap.app/Contents/MacOS/libAudiointerposingLeo.dylib
So, I looks like another application on the user’s computer was responsible for the crash. Unfortunately it was Übercaster’s process which was killed by this, resulting in the user’s conception that Übercaster’s ability to record Skype conversations is faulty…
I guess, you get the point…
One last, recent example (I’m still working on this one!):
I recently received crash reports from some users, having problems during releasing AAC files with Übercaster.
The backtrace in the crash reports (i.e. the location where Übercaster crashed), looked always like this:
0 libSystem.B.dylib 0x96fd0732 __kill + 10 1 libSystem.B.dylib 0x96fd0724 kill$UNIX2003 + 32 2 libSystem.B.dylib 0x9706398d raise + 26 3 libSystem.B.dylib 0x970799d9 __abort + 124 4 libSystem.B.dylib 0x9705c71c release_file_streams_for_task + 0 5 ....audio.toolbox.AudioToolbox 0x9317fe2f UInt32ToHexString(...) + 183 6 ....audio.toolbox.AudioToolbox 0x9317feee MP4AudioFile::FillGaplessString(...) + 110 7 ....audio.toolbox.AudioToolbox 0x93182d85 MP4AudioFile::Close() + 627 8 ....audio.toolbox.AudioToolbox 0x930de085 AudioFileClose + 77 9 ....audio.toolbox.AudioToolbox 0x93141380 ExtAudioFile::Close() + 206 10 ....audio.toolbox.AudioToolbox 0x931414c8 ExtAudioFile::~ExtAudioFile() + 40 11 ....audio.toolbox.AudioToolbox 0x93136d20 XExtAudioFile::~XExtAudioFile() + 92 12 ....audio.toolbox.AudioToolbox 0x931369d8 ExtAudioFileDispose + 37 13 ...pleasantsoftware.ubercaster 0x000f6624 CAAudioFile::Close() + 26 14 ...pleasantsoftware.ubercaster 0x000f5f31 CAAudioFileConverter::ConvertFile(...) + 3545 15 ...pleasantsoftware.ubercaster 0x000d6f5a -[ReleaseSlot encodeToAAC:] + 2748 ...
That’s a rather weird location inside Apple’s CoreAudio framework (to be exact, the AudioToolbox framework). Especially since the crash seems to happen when closing the encoded file, i.e. after the whole thing is more or less done, all input files read, mixed, sampled, compressed and so on.
In addition to that, the code in Übercaster surrounding the CoreAudio AAC encoding, didn’t change since several versions and didn’t cause any problems before.
So I checked all other crash reports, we received in the last months, for similar issues.
It turns out, that there are several other reports on the same problem.
Interestingly, all these reports were sent from a computer running Mac OS X 10.6.2 (10C540). The oldest report was sent at December 29, 2009. I didn’t find any reports matching this problem before that date.
Mac OS X 10.6.2 was released at November 9, 2009.
I’m still not sure what’s wrong, but there appears to be a connection between the latest Mac OS X release and the AAC encoding problems, some users experience.
Unfortunately I don’t know what Apple changed in CoreAudio (or elsewhere) what might cause these problems (there’s no hint on this in the official release notes). But I definitely know, that Übercaster runs the very same code when encoding AAC since several months without any problems and there is no single crash report on this before December 29.
That said, I checked the reports again, this time looking for other crashes concerning encoding/releasing audio.
I found some crash reports, where the crash happened during encoding MP3.
Übercaster encodes MP3 with the LAME framework (an open source MP3 encoder, so definitely not Apple’s code).
Interestingly, Übercaster didn’t crash inside the LAME framework or any native Übercaster code, but again inside CoreAudio or more accurately the AudioToolbox framework. That’s the exact same framework (provided by Apple) which is also involved in the crashes in the other reports.
The oldest were from October 11, 2009 and all found reports were sent either from a Mac OS X 10.6.2 or 10.6.1 machine (Mac OS X 10.6.1 was released on September 10, 2009).
This might all be a coincidence, but I rather think not.
I’ll definitely try to find out as fast as possible what exactly Apple did change in CoreAudio recently and how these changes cause Übercaster to crash.
To sum things up:
Please…
- send us crash reports from within Übercaster!
- use the comment field to give as much details on the circumstances of the crash as possible.
- if possible, describe a way to reproduce the crash.
- don’t use the comment text field in the crash reporter for support requests.
- don’t expect a reply to your crash report. Write an additional support mail for that.
- remember that there’s a (not too small) possibility that it’s not Übercaster’s code, causing the crash.
Thank you!
Finally: We’re switching to the new Birdie Online Course Editor tonight!
At June 8, this year’s WWDC (Apple’s world wide developer conference) starts in San Francisco, CA. As in the past years, I’ll be there as an attendee, learning all news around Mac and iPhone development (I hope).