On 9 June 2015 at 21:52, Alexander E. Patrakov <patrakov at gmail.com> wrote: > 09.06.2015 12:08, arun at accosted.net wrote: >> >> From: Arun Raghavan <git at arunraghavan.net> >> >> When we the underlying sink/source goes away, there is an intermediate >> state where the asyncmsgqs that we were using for the sink-input and >> source-output go away. This is usually okay if the sink-input and >> source-output are moved to another device, but can be problematic if we >> don't support moving (which is the case when the filter is autoloaded). >> >> This becomes a problem because of the following chain of events: >> >> * The underlying sink goes away >> >> * Moving the filter sink-input fails (because it is autloaded) >> * At this point the sink-input has no underlying sink, and thus >> no underlying asyncmsgq >> * This also applies to all sink-inputs connected to the echo-cancel >> module >> >> * The sink-input is killed, triggering a module unload >> >> * On unlink, module-rescue-streams tries to move sink-inputs to >> another sink, starting with a START_MOVE message >> >> * There is no asyncmsgq for the message, so we crash >> * We can't just perform a NULL check for the asyncmsgq, since there >> are state changes we need to effect during the move >> >> To fix this, we pretend to allow the move to the new sink, and then >> unlink ourselves *after* the move is complete. This ensures that we >> never find ourselves in a position where we need the underlying >> sink/asyncmsgq to be present when it is not. >> >> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=90416 > > > > I see that there is also a patch for module-equalizer-sink, but no patches > for module-remap-sink, module-virtual-surround-sink and module-virtual-sink > (i.e. the example). If patches are not required there, it would be nice to > mention this explicitly here in the commit message. It should be implicit since only the autoloaded filter modules (which remap etc. are not) suffer from this problem. I can add that, though. -- Arun
