What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

------- Comment #1 from  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.


Reply via email to