[Gc] Difference between version 6.1 and latest which is 6.4

Emmanuel Stapf [ES] manus at eiffel.com
Mon Jun 20 12:29:58 PDT 2005


> I can't immediately think of a reason for that.  If it's easy 
> to do, you might try 6.5 as well, though I'm not sure why it 
> would help.
> I also don't recall other similar issues being reported.

Updated to 6.5 and got the same problem. By the way the default source download
link will download 6.4 and not 6.5.
 
> Under Windows, the root scanning code was changed to scan 
> only from MEM_IMAGE mappings.  This should be enough to catch 
> dynamic library data, or at least so we believe.  If you were 
> relying the collector tracing from other kinds of memory 
> mappings, that might explain the problem.
> If that is indeed the issue, it would be good to understand it better.

How do I revert to the previous scanning in 6.5 so that we can figure out if this
is the problem or not?
 
> If all else fails, there are some hints for tracking down 
> premature deallocation issues at
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html

I've done some debugging, but I'm not sure to understand the results better. After
adding GC_DEBUG and GC_ASSERTIONS, it crashes much earlier. The crash occurring
after the second call to `GC_finish_finalization'. Doing `GC_find_header' on my
allocated block shows that the block was last reclaimed at the second cycle. The
strange thing is that just after allocating it, it reports it was reclaimed at the
first cycle.

At the point of the crash, my code is trying to access some memory which should be
alive, but it has been zeroed. My block is referenced in my C code by a local
variable, the C generated output is optimized and I don't clearly see where the
reference is stored. The fact the code is optimized should not matter as it works
just fine with 6.1 (same code, but linked with gc.lib from 6.1 rather than from
6.5)

Although I tried GC_dump but nothing gets printed. Is it not working on windows
from the VS debugger?

I've tried enabling ALL_INTERIOR_POINTERS and it fails much later, but still
fails. By the way, although I never noticed it before, I've been using
`GC_register_displacement (8)', but I've noticed that the implementation of
`GC_is_valid_displacement' will fail if the block is larger than a certain size?
Does it mean that I cannot use `GC_register_displacement' at all if I cannot
guarantee that my blocks will be smaller than a certain size?

Thanks,
Manu

PS: I'm using VC++ 6.0 sp5 in case it matters.



More information about the Gc mailing list