[pulseaudio-discuss] [PATCH] loopback: Fix crash if Max Request change at unload

[Dalleau, Frederic]

Hi Arun,

On Tue, Feb 21, 2012 at 4:13 AM, Arun Raghavan
<arun.raghavan at collabora.co.uk> wrote:
> 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?
>

In theory yes, but you first need to access the thread_mq which (imho)
isn't accessible from the sink.
For example, in case of module-bluetooth-device, it is in struct user_data.

There is also the problem that other messages can be waiting in outq
and have to be executed
while the specific message we want to flush do not need to be executed.

Frédéric