Re: Crash on quit - AudioOutputUnit app
Re: Crash on quit - AudioOutputUnit app
- Subject: Re: Crash on quit - AudioOutputUnit app
- From: Philippe Wicker <email@hidden>
- Date: Fri, 6 Jun 2003 22:53:36 +0200
On Friday, June 6, 2003, at 05:58 PM, Rolf Nilsson wrote:
>
But I just got the crash log below from a beta tester with a dual
>
processor system and would like help to understand what it means (it
>
crashed when the user closed down the application).
>
>
To my understanding it crashed (Thread 0) when de-alocating some static
>
objects after main() has finished?
>
Yes, you're right. Usually, this kind of crash happens either because
the "static" object (or members of this static object) have already
been destroyed, or because it contains members which are pointers on
some other objects. These pointed objects may have already been
destroyed, or the pointers to them are incorrectly initialized, or they
(the pointers) have been corrupted. If your beta tester can reproduce
the crash, it could be useful to have any messages printed out on the
console (such as malloc double free, etc ...).
>
>
Thread 2 has the following line
>
_ZN10HALRunLoop9OwnThreadEPv
>
>
HALRunLoop - does this mean that the AudioOutPutUnit is still running
>
even though I called
>
>
AudioOutputUnitStop(m_outputAudioUnit);
>
and
>
CloseComponent(m_outputAudioUnit);
>
In my opinion, the IO thread is not running anymore. I don't know what
is the role of thread 2 but if you run AudioUnitHosting under the
debugger you can notice that this thread is running while the rendering
is done in another thread (XThreadedDevice::IOThreadEntry).
>
btw, is AudioOutputUnitStop() synchronous (I guess it is)?
>
i.e. when AudioOutputUnitStop() returns, the render callback will never
>
be called again?
>
>
Thread 3 is my render thread that is for sure destroyed before main
>
exits. Does this mean that it crashed inside the main program thread
>
anyway?
>
Your application looks to be written in C++. The C++ runtime does not
know anything about threads running within your app. I mean that if for
some reason your main thread exits, threads still running are not
killed before the main thread executes the exit, but some times later
by the system (I don't know exactly when). According to the crash log,
threads 1, 2 and 3 are still alive. All of them are waiting for some
events to occur.
>
Help/explanation appreciated
Hope this will help. BTW, I've tested your app (2.5.8 Mach-O beta 1) on
my DP867, works fine, no crash :-))
>
Rolf Nilson
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.