On 03/20/2012 06:10 PM, Dalleau, Frederic wrote: > Hi David, > > On Tue, Mar 20, 2012 at 4:06 PM, David Henningsson > <david.henningsson at canonical.com> wrote: >> On 02/10/2012 05:39 PM, 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. >> >> >> Hmm, I saw this as well and committed a patch for it today (before I checked >> this post unfortunately!) >> >> Would you mind reviewing my patch "Never call adjust_rates after teardown" >> to see if it affects/resolves your problem as well? >> > > I'm in the middle of something, I hope I can look at your patch within > a day or two. > From reading the code, I think it could reduce bug frequency. > Have you reproduced the crash yourself? No, I just saw the crash report on launchpad and tried to figure out the likely cause for it. The person in question had combined module-null-sink with module-loopback and got a segfault from sink_input_update_max_request calling adjust_rates with a null u->source. For reference, the stack trace is here: https://bugs.launchpad.net/bugs/946400 -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
