On Fri, 2012-02-10 at 17:39 +0100, Fr?d?ric Dalleau wrote: > Module-bluetooth-policy can load and unload module-loopback on demand. > Sometimes if there is an error, module-loopback can be unloaded early. > When module-loopback is loaded, it attaches a sink and the sink > calls sink_input_update_max_request for which there is a callback. > In this callback, module-loopback will queue a message in order to > process it from main thread. The message is queued in the sink > thread queue. > > There is a possibility that this message is not processed if unload > has been requested. When this happens, the message > is still in the queue, and will eventually be processed. This triggers > segfault because the message carries a pointer to the no > longer existing sink input. > > The fix is inspired by pa_thread_mq does for registering a thread specific > message queue. The idea is to create a module-specific queue. Any pending > message at unload will be flushed without processing. > --- Thanks for the very nice, detailed analysis in the log message. Would this also be fixed by doing a pa_asycmsgq_flush() on the thread's outq during teardown? Cheers, Arun
