GC_mark_stack_bottom interpreted as heap pointer?

[Ringdingcoder]

While investigating a bug report in CACAO, I translated the relevant bits of the test program to C, and now I can reproducibly make the GC run out of memory. The orphaned entries form a chain of entries, so holding on to just one of them ensures that nothing is ever reclaimed. Using GC_TRACE and GC_generate_random_backtrace, I can at least make a guess at what happens here. GC_mark_stack_bottom () is in the root set -- what for? -- and points to the lower heap bound (). Following it, ..0x30 gets marked for some reason, and it's game over from there. This happens with 7.2d (and with every 7+ release). Release 6.8 is the most recent one I could find which does not behave that way.

I'm aware that the test is probably the worst possible scenario for a conservative garbage collector, but I still wonder why the GC_mark_stack_bottom variable is treated as a heap pointer. It's also possible that my interpretation of the trace output is off. It's not easy for an outsider to find out what's really going on.

EDIT: Hmm, it doesn't seem to be possible to add an attachment here… – https://github.com/Ringdingcoder/dumpingground/blob/master/gc-chain.c

[ivmai]

I can't find GC_mark_stack_bottom. Do you mean GC_mark_stack_top? Do you have any patch solving the problem?
Anyway, please repost this issue to gc@linux.hpl.hp.com

[Ringdingcoder]

Apparently I got this mixed up, since I wrote "GC_mark_stack_top" in the CACAO bug entry.

No, I don't have a patch.

[Ringdingcoder]

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.

[ivmai]

I've applied a fix preventing GC_mark_stack* pointers from being scanned. Could you please check whether the CACAO problem disappeared.

[ivmai]

Stefan Ring reported n GC mailing list:

I have tried your patch a few days ago, and the end result is the same
as before :(.

However, with my C test program, I can verify that the tracing root is
now some pointer on the stack, not one of these internal variables.
I’ll have a more detailed look where these stray – which they seem to
be – pointers are coming from, but I guess there’s not a whole lot
that can be done about it anyway.