On Wednesday 04 July 2007 15:17:33 Mark Glines wrote:
> It helps, thanks. Glad to know I can't just blame gentoo.
> After doing the binary search I mentioned earlier and finding that it
> started breaking in svn r19441, there was some discussion in the IRC
> channel. The important bit is:
>
> [13:35] <@chromatic> Hm, I don't blame 19441 for the shootout test.
> [13:35] <@chromatic> I think it just changed the memory characteristics of
> the program sufficiently to trigger a lurking GC bug.
>
>
> So now I'll try to see if there was a DOD run that freed up something
> it shouldn't have, or something like that.
I see the segfault now during global destruction:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212667696 (LWP 25316)]
0xb7ddb7db in Parrot_dod_sweep (interp=0x804e008, pool=0x806eb60)
at src/gc/dod.c:641
641 VTABLE_destroy(interp, p);
(gdb) bt
#0 0xb7ddb7db in Parrot_dod_sweep (interp=0x804e008, pool=0x806eb60)
at src/gc/dod.c:641
#1 0xb7ddbf37 in Parrot_dod_ms_run (interp=0x804e008, flags=4)
at src/gc/dod.c:987
#2 0xb7ddc097 in Parrot_do_dod_run (interp=0x804e008, flags=4)
at src/gc/dod.c:1051
#3 0xb7d73173 in Parrot_really_destroy (interp=0x804e008, exit_code_unused=0,
arg_unused=0x0) at src/inter_create.c:316
#4 0xb7ddcbe0 in Parrot_exit (interp=0x804e008, status=0) at src/exit.c:78
#5 0x08048954 in main (argc=1, argv=0xbfa20a48) at src/main.c:65
(gdb) p p->vtable
$3 = (VTABLE *) 0x0
(gdb) x p
0x8218638: 0x00000005
That looks very suspicious.
-- c
