-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 28 Dec 2005, Jorrit Tyberghein wrote:
The idea is that the block allocator should be empty at the time it is destructed. When this problem manifests itself it means there is a leak elsewhere in the engine (for example if the objects in that kdtree are leaking). 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).
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.
... I'd also point out that in this case, the crash is coming from csInitializer::DestroyApplication(), which really ought be able to handle the case where there are still objects in the engine.
I should say that on looking at the stack trace a bit more, it's hard to say 100% for certain that the problem Anders is having is precisely the same as mine, but there still may be a connection. The gist of the problem is that the block allocator is not reentrant, even in a non-threading sense, that is: if in the process of deleting object A, the destructor deletes objects B, C and D from the same allocator, when it gets back to finishing the delete of A the allocator may have shuffled stuff around and become inconsistant with respect to the original operation of deleting A.
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDsxBtaeHUyhjCHfcRAgmTAJ9eF5ctpCxPHI+1fA2j/lHpWHqCowCggpM9 6hfIrPefSb/QkiqFFDI5p+U= =51Gb -----END PGP SIGNATURE----- ------------------------------------------------------- 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]
