On Wed, Oct 9, 2013 at 12:26 PM, Jo?o Paulo Rechi Vita <jprvita at gmail.com> wrote: > On Tue, Oct 8, 2013 at 12:15 PM, Tanu Kaskinen > <tanu.kaskinen at linux.intel.com> wrote: >> On Tue, 2013-10-08 at 11:19 -0300, Jo?o Paulo Rechi Vita wrote: >>> On Sun, Sep 29, 2013 at 1:39 PM, Tanu Kaskinen >>> <tanu.kaskinen at linux.intel.com> wrote: >>> > On Tue, 2013-09-24 at 19:45 -0300, jprvita at gmail.com wrote: >>> >> +void pa__done(pa_module* m) { >>> >> + struct userdata *u; >>> >> + >>> >> + pa_assert(m); >>> >> + >>> >> + if (!(u = m->userdata)) >>> >> + return; >>> >> + >>> >> + if (u->bluez5_module) >>> >> + pa_module_unload(m->core, u->bluez5_module, true); >>> >> + >>> >> + if (u->bluez4_module) >>> >> + pa_module_unload(m->core, u->bluez4_module, true); >>> > >>> > This crashes when shutting down the daemon, because when the daemon >>> > unloads all modules, module-bluez*-discover gets unloaded before >>> > module-bluetooth-discover, so the y->bluez5_module and u->bluez4_module >>> > pointers become stale. I see two ways of fixing this: add a hook that is >>> > fired when modules are unloaded and use that hook in >>> > module-bluetooth-discover to drop the reference to the unloaded module, >>> > or unload module-bluetooth-discover immediately after loading >>> > module-bluez5-discover and module-bluez4-discover. The second solution >>> > is of course much simpler, but I proposed that already earlier, and you >>> > didn't like that. >>> > >>> >>> It doesn't crash (and that's what I'm experiencing here) because >>> pa_module_unload() will look for that module pointer in its internal >>> hash of modules before trying to unload it. I agree we are left with a >>> stale pointer, but as long as we don't dereference it, we should be >>> fine. >> >> pa_module_unload() dereferences the pointer already before >> >> if (!(m = pa_idxset_remove_by_data(c->modules, m, NULL))) >> return; >> >> which I think you are referring to as the safeguard. The line that >> crashes is this: >> >> if (m->core->disallow_module_loading && !force) >> Hum, another thing came to my mind: pa_module_unload() also receives the pa_core pointer through its arguments, why not use it in the check for disallow_module_loading? Like this: if (c->disallow_module_loading && !force) -- Jo?o Paulo Rechi Vita http://about.me/jprvita