[Gc] bug? or misunderstanding?

Andrew McKinlay mckinlay at axonsoft.com
Tue Feb 14 09:51:57 PST 2006

I'm trying to track down a problem with a memory block being prematurely

The block is just over 4 k (4104). The pointer to it (which should keep it
alive) is an interior pointer to an offset of 0xff3 (4083).

e.g. base 0x3d85000, pointer 0x3d85ff3

I verified that in GC_finish_collection the block is not marked (i.e. is
getting collected)

The header of the block is:

{hb_sz = 1026, hb_next = 0x3911000, hb_prev = 0x0, hb_descr = 0,
  hb_map = 0x1640000 "", hb_obj_kind = 0 '\0', hb_flags = 0 '\0',
  hb_last_reclaimed = 32, hb_marks = {0 <repeats 32 times>}}

Then I added a global pointer in case it wasn't seeing the actual pointer.

- if I set this pointer to the offset address the block is still prematurely

- if I set this pointer to the base address it fixes the problem - the block
is kept alive

It appears that as long as the pointer is within the first roughly 1000
bytes of the block it works. But if it is offset more then  the block gets
prematurely collected.

The block is allocated with GC_malloc_atomic (it doesn't contain any

The collector (6.5) is built with -DALL_INTERIOR_POINTERS. This is on
Windows XP with MinGW GCC 3.4.3

It appears to be working as if I had used GC_malloc_ignore_off_page, but I

I haven't tried to make a simple test program that recreates the problem,
but I can try that if it would help.

Any suggestions or explanations would be appreciated.

Andrew McKinlay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20060214/017cff78/attachment.htm

More information about the Gc mailing list