[Gc] RE: [bdwgc] GC_mark_stack_bottom interpreted as heap pointer? (#21)

Boehm, Hans hans.boehm at hp.com
Mon Aug 26 14:07:30 PDT 2013

This suggests to me that we might want to move GC_mark_stack_limit into _GC_arrays, so that it's not traced from.  I don't think that should have adverse performance impact, but I'm not 100% sure.



From: Stefan Ring [mailto:notifications at github.com] 
Sent: Sunday, August 25, 2013 5:19 AM
To: ivmai/bdwgc
Subject: Re: [bdwgc] GC_mark_stack_bottom interpreted as heap pointer? (#21)

I've just tried to reproduce this using a more recent version – ca89b8c –, as I could not remember exactly what I did back then.
I compile with KEEP_BACK_PTRS and call GC_generate_random_backtrace() at every step. After a while, most of these traces will say:
0x663f80 (tests/middle.c:114, sz=24, NORMAL)
Reachable via 241 levels of pointers from offset 8 in object:
0x663030 (tests/middle.c:114, sz=24, NORMAL)
Reachable via 242 levels of pointers from root at 0x601388
And what lives at 0x601388?
(gdb) x/1gx 0x601388
0x601388 <GC_mark_stack_limit>: 0x0000000000663000
So I'm not sure which one of these GC_mark_stack* variables it was last time, but this is what I'm getting now.
Reply to this email directly or view it on GitHub.

More information about the Gc mailing list