GC_mark_stack_bottom interpreted as heap pointer? about bdwgc HOT 5 CLOSED

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 [email protected]

from bdwgc.

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.

from bdwgc.

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.

from bdwgc.

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

from bdwgc.

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.

from bdwgc.