On Monday 03 March 2008 18:26:47 Will Coleda wrote:
> Tcl is exposing another GC bug (even on feather.)
>
> build tcl, then prove t/cmd_array.t
That didn't do anything for me. Deleting the Perl boilerplate in the file and
running the test through ../../parrot tcl.pbc did.
> Backtrace from GDB is:
I usually need more than a backtrace to debug these.
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb6e326c0 (LWP 20500)]
> 0xb7cb1a39 in new_pmc_ext (interp=0x804f008) at src/headers.c:343
> 343 pool->free_list = *(void **)ptr;
What's the invalid pointer here? (My guess is ptr, which my own debugging
shows to be the case.) To find out, you have to:
(gdb) p ptr
... or:
(gdb) p *ptr
... and see what complains.
Okay, now that we know that ptr is invalid, we have to figure out what put an
invalid pointer on the free list. For the mark and sweep garbage collector,
the function is gc_ms_add_free_object(), so we can set a breakpoint in
src/gc/smallobject.c:172 with a conditional that to_add has to equal ptr at
the point of segfault. That'll let us figure out which object contains this
invalid pointer and, perhaps, why.
In this case, the backtrace isn't entirely useful, except for:
> (gdb) bt
> #0 0xb7cb1a39 in new_pmc_ext (interp=0x804f008) at src/headers.c:343
> #1 0xb7cb1994 in new_pmc_header (interp=0x804f008, flags=67109888)
> at src/headers.c:304
... which indicates that whatever the problem is, there's something getting
freed to the PMC_EXT pool inappropriately.
I'm still waiting for gdb to reach that line, by the way. This is why having
a stripped down PIR test case is so nice. If things don't clear up by the
time I can't type anything else sensible here, I'll delete all but that
failing test case from the test file and see if I can reproduce the behavior.
I hope this is useful to help other people get further along in debugging
these types of things. (Do we have someone mining bug reports for debugging
tips to put on the wiki or in the docs?) I'll continue to investigate.
-- c
