On Dec 28, 2005, at 5:23 PM, Peter Amstutz wrote:
On Wed, 28 Dec 2005, Jorrit Tyberghein wrote:
So the proper fix for this problem is to fix the leak.
In an ideal world, yes, the application would go through and
carefully clean everything up before exiting. On the other hand
one could argue that this is redundant work, since the operating
system is going to reclaim those resources no matter what just as
soon as the program terminates (and do so more efficiently since it
doesn't care about what data was there).
For anyone entering the thread at this time, I'll reiterate: The
actual crasher described at the beginning of this thread was a double-
deallocation attempt of a managed object. It was not caused by a leak.
At any rate, when I rewrote csBlockAllocator from scratch earlier
this year, I changed the behavior so that the allocator itself is now
responsible for destroying the objects which it has vended if they
have not already been destroyed by the time the allocator itself is
destroyed. This differs dramatically from the original implementation
of csBlockAlllocator which forced clients to discard each vended
object manually before the allocator itself was destroyed. By
"forced", I mean that it would throw an assertion if vended objects
still remained. This was hostile behavior. In my opinion, utility
classes, such as this, should reduce the work of clients rather than
increase it.
The problem that I found was that the particular instance of block
allocator for kdtree nodes is declared as a static global instance
object. This means that it is set up by the compiler to always run
the destructor as part of the post-exit() or plugin-unloading
cleanup routine! So if the application has left *anything* in the
block allocator list prior to calling exit() or closing the plugin
there is potentially a crash because the destructor for every node
still in the block allocator is going to be executed as part of
that automatic cleanup. So then you get into the double-free crash
case I described in my previous email.
Use of global static objects is heavily frowned upon and certainly
sounds problematic in this case. Note also that the original
implementation of csBlockAllocator never performed any sort of
automatic destruction of vended objects, so it is possible that my
rewrite, in which I made the allocator responsible for destroying the
objects it vended, may have allowed this already potentially bogus
case to manifest.
I seem recall from your original mail a couple months ago that you
discovered that the kdtree nodes are themselves referencing other
kdtree nodes, and that as a node is destroyed, it re-entrantly
destroys the nodes it references. Is this correct? Depending upon the
architecture of the kdtree code, one possible solution is to remove
from kdtree node the responsibility of destroying its child nodes,
and instead let those nodes get destroyed automatically by the
allocator when the allocator itself is destroyed. Another possible
solution, I suppose, would be to make the allocator's auto-
destruction sequence more robust against this sort of re-entrant
destruction.
-- ES
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
