|
From: Christian P. <tr...@ge...> - 2005-08-12 23:54:09
|
On Friday 12 August 2005 14:36, you wrote: > On 8/12/05, Christian Parpart <tr...@ge...> wrote: > > If that's so, than it's a leak I didn't close and that's why I still have > > that old (orphaned) pointer around in this list; > > We've had problems in our code base where SmartPtr's have been trying > double delete when linking dynamically. It seems to be some thing > related to a global symbol in the library that some how appears in the > executable, so that when the library is unloaded the memory is > cleared, then when the exectuable is unloaded it tries to clear the > memory again. > > This was fixed by having the SmartPtr zero out it's pointer > immediately following the deletion, so that there is nothing to try to > delete the second time. If this change fixes it, you may have hit the > same kind of weird compiler case that we did. It looks like there are > multiple SharedPtr destructors in your call stack, so that could, > also, confuse the issue. I reduced it to a single shared-ptr within the stacktrace by simply switching to another (more simple / less powerfull) collection class; > You could try accessing the raw pointer prior to deleting it to see if > it has already been deleted, and by whom. I am on it... (and will give a notice when I got fixed that *****) > P.S. Is there possibly an inter-plugin dependency? nope, both modules do not know each other; both do know the upper layer, that is, the server API, of course, in which it is (just like apache) registering/unregistering hooks to get notified about certain events; when unregistering these hooks in the server (from within the to-be-unloaded module) it comes to this behavior (the second module unload); Regards, Christian Parpart. -- 01:48:16 up 142 days, 14:55, 2 users, load average: 1.16, 0.95, 1.29 |