On Fri, 2012-03-23 at 16:19 +0100, David Henningsson wrote: > On 03/23/2012 02:47 PM, Dalleau, Frederic wrote: > > Hi David, > > > >> For reference, the stack trace is here: > >> > >> https://bugs.launchpad.net/bugs/946400 > > > > It is likely that the issues related : here is the backtrace I got > > after applying your patch (without mine) > > > > #0 0xb7e9b520 in adjust_rates (u=0x80b3668) at modules/module-loopback.c:174 > > #1 0xb7e9d372 in sink_input_process_msg_cb (obj=0x80f2728, code=10, > > data=0x0, offset=0, chunk=0x0) > > at modules/module-loopback.c:530 > > #2 0xb7c31f9b in pa_asyncmsgq_dispatch (object=0x80f2728, code=10, > > userdata=0x0, offset=0, memchunk=0xbfffe96c) > > at pulsecore/asyncmsgq.c:322 > > #3 0xb7c320e1 in pa_asyncmsgq_flush (a=0x8100ea0, run=true) at > > pulsecore/asyncmsgq.c:347 > > #4 0xb7c990fa in pa_thread_mq_done (q=0x80a7da0) at pulsecore/thread-mq.c:107 > > #5 0xb7ced418 in stop_thread (u=0x80a7d70) at > > modules/bluetooth/module-bluetooth-device.c:2455 > > #6 0xb7cedf1f in card_set_profile (c=0x80a6a98, new_profile=0x80b1ed8) > > This is puzzling. Exact what is it failing on and why? Could you set a > breakpoint right before the crash, and examine the relevant values? At least in the situation where the SINK_INPUT_MESSAGE_MAX_REQUEST_CHANGED message is processed after module-loopback has been unloaded, adjust_rates() will crash if it's called. Your patch sets adjust_time to zero at teardown, which reduces the changes of adjust_rates() getting called, but when module-loopback gets unloaded, that particular memory location may get overwritten with a non-zero value. -- Tanu
