Pleasant Software Blog | Support  


The principle of cause and effect


lynch mobOf 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!

3 Comments

  1. Comment by fALk on April 8, 2010 2:42 pm

    Sorry for all the AAC crash reports but at the moment this bug is so problematic that we can´t do any podcasts. I haven´t been able to release a single aac from übercaster since december. if there is anything you can do to patch this I think this is a rather important bug to fix. I have been recreating chapters in Garageband – not fun as this is the reason that we use übercaster in the first place. I know apple is not the most open and there are tons of problems in coreaudio so I don´t completely blame you. still this is your programs core functionality and should at least work sometimes ;)

  2. Comment by admin on April 17, 2010 10:16 am

    fALk, it seems you blamed the wrong guy (again).

    Here’s an excerpt from a response to a DTS request on the subject, I finally received from Apple a few days ago:


    “MP4AudioFile::FillGaplessString
    There was a related bug that [AudioToolbox] MP4AudioFile::Close crashes writing large files, but it was fixed already since Mac OS X 10.6.3. Please ensure to upgrade to the latest Mac OS X.”

    The MP4AudioFile::FillGaplessString is the very problem which caused the crashes during AAC export (as described in the post above). Sure enough, I double-checked the crash reports I received on the problem and they are indeed all sent from Macs running Mac OS 10.6.1 or 10.6.2.

    There’s more on another crashing problem in Übercaster (which also suddenly occurs with the Mac OS X 10.6.1 update). This second problem erratically occurs when playing back audio on the cut layer (resulting in a crash). Since I couldn’t find any bug in my source code I also sent a DTS request to Apple on this. They already confirmed, that the crash is caused by a new check function inside CoreAudio, they introduced (undocumented!) in Mac OS 10.6. Unfortunately, after checking all possible reasons (named by Apple) for a fail of this new function, it’s still unclear what causes the crashes. So this one is still pending.

    I’ll write on this in more detail, as soon as I get more information from Apple and/or the mist clears a bit more.

  3. Pingback by Pleasant Software » Übercaster v1.6.5 beta1 on April 17, 2010 5:31 pm

    [...] I received a lot reports on 2 other crashing bugs lately. Both bugs drove me almost crazy and forced me into some very frustrating bug hunting. [...]

Comments RSS TrackBack Identifier URI

Sorry, the comment form is closed at this time.


Pleasant Software is proudly powered by WordPress and themed by Mukka-mu (customized)