On 10/10/2011 08:11 AM, Jonathan Woithe wrote:
> Hi David
>> I don't understand how to create a TRAC account (where's the
>> "register account" link?), ...
> I can't honestly remember. It may be that a registration on the main ffado
> site also then permits you to log into trac.
>> ... so answering here instead.
> Yep, that's all good.
>> I can reproduce the crash, and have attached a patch which fixes it here.
> Awesome. I'll have a look at it in detail this evening.
>> First, debug modules are not allocated pointers, in fact, the
>> standard way of making one (using DECLARE_DEBUG_MODULE macro) does
>> not. Therefore you must not delete it.
> Ah right. That's a detail I missed when going through the code; the
> pointers in the vector are therefore in reality pointers to statically
> allocated objects. That'll cause issues for sure if a delete is attempted.
>> Second, DebugModuleManager::instance() becomes a dangling pointer
>> after the instance has been deleted, so DebugModule instances must
>> not reference it.
> I'll have to look at this more closely; I wasn't aware that it was possible
> for any DebugModule objects to exist beyond the life of the
> DebugModuleManager. If the manager object has been deleted then all debug
> modules (which must be registered with it, almost by definition) should have
> been deleted as part of the manager object's destructor.
> At least would appear to be the original design idea. In reality though it
> breaks down due to the debug modules being static objects. Therefore even
> though the intent was that all debug objects are "closed down" at the end,
> in practice they are still around and could conceivably be called into
> To be true to the original design intent the correct course of action is
> probably to ensure that DebugModuleManager::instance() does the right
> thing after the debug manager is deallocated and doesn't become a dangling
That is correct. Exactly what to do when trying to access
DebugModuleManager::instance() after that instance has been destroyed,
I'm happy to leave that to you to decide. Some kind of assertion failure
> However, all this has been written quickly, from memory, and could
> be totally bogus. I'll go through it slowly myself this evening and see
> what I come up with.
> Suffice to say that I'm not certain that the value of
> DebugModuleManager::instance() following deletion of the manager is a real
> issue. That's not to say that this shouldn't be cleaned up, but I'd be
> surprised if this was the underlying issue. Attempting to delete the static
> debug module objects themselves, coupled with the iterator problem already
> noted, is more likely to be the root of these problems.
From my debugging session this morning, I can tell for sure that just
changing the removal loop in ~DebugModuleManager (to "while non-empty do
unregisterModule()") did not resolve the problem completely - it crashed
later, and I'm quite certain that is because ~DebugModule calls
DebugModuleManager::instance()->unregisterModule(), with the
DebugModuleManager instance being a dangling pointer.
I don't know if the destruction order is specified by C++ for static
objects, but since ~DebugModuleManager is called on dlclose() that might
come first. Or maybe it came last, until some changes in below layers
(gcc, libc etc) changed it to come first - I don't know, for some reason
it seems a little strange that this error occurs now when there has been
no changes to that code for the last two years.
David Henningsson, Canonical Ltd.