http://d.puremagic.com/issues/show_bug.cgi?id=2895
fvbom...@wxs.nl changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Comment #1 from fvbom...@wxs.nl 2009-04-25 07:10 ------- This is a bug in your code. Don't access GC-allocated memory from the destructor unless you're sure it won't be collected before the destructor is called. In this case, the likely sequence of events when the GC runs on program exit is as follows: 1) The GC sees the File is no longer referenced from any root, and frees its memory pool slot. 2) Since it was the last (only) item in its memory pool, the memory for the pool gets unmapped. 3) The GC determines there are no more references to your XXX. 4) The GC first calls the destructor for the XXX. 5) The destructor accesses unmapped memory (previously known as a File) and triggers an access violation. If you shrink the XXX class by removing members, it probably shrinks enough to be put into the same pool as the File object (which is presumably smaller). This causes the File to no longer be the last item in its memory pool just before it gets collected, so the pool is not freed yet. The XXX destructor then accesses deallocated (but not unmapped) memory before returning and letting the program close down gracefully, without detecting the bug. --