I was finding that t/pmc/objects.t tests 40-45 were failing with a SIGBUS.
Running t/pmc/objects_40.imc
The stack backtrace revealed that the cause was jumping to a garbage address
in the call node->function in Parrot_exit:
void Parrot_exit(int status) {
handler_node_t *node, *next_node;
/* call all the exit handlers */
for (node = exit_handler_list; node; node = next_node) {
(node->function)(status, node->arg);
next_node = node->next;
mem_sys_free(node);
}
exit(status);
}
So I placed a breakpoint on the for statement, ran it again, and got very
confused about why the loop didn't seem to stop at the NULL pointer in the
linked list chain, and ended up with garbage. And for some reason it wasn't
even reaching the mem_sys_free() on the last (proper) node - the point I
was investigating.
It was only after some time that I tried a stack backtrace at this point.
Previously I'd done a stack backtrace when I first hit the breakpoint.
And:
(gdb) where
#0 Parrot_exit (status=74) at src/exit.c:75
#1 0x0002b594 in internal_exception (exitcode=74, format=0x286ca0 "destroy() not
implemented in class '%s'") at src/exceptions.c:56
#2 0x000cbd58 in Parrot_default_destroy (interpreter=0x1000200, pmc=0x1017bb8) at
classes/default.c:189
#3 0x001f92dc in Parrot_deleg_pmc_destroy (interpreter=0x1000200, pmc=0x1017bd0) at
classes/deleg_pmc.c:143
#4 0x0002d990 in free_unused_pobjects (interpreter=0x1000200, pool=0xd002e0) at
src/dod.c:718
#5 0x0000a868 in Parrot_really_destroy (exit_code=0, vinterp=0x1000200) at
src/inter_create.c:312
#6 0x0000ab90 in Parrot_exit (status=0) at src/exit.c:76
#7 0x00004400 in main (argc=1, argv=0xbffff764) at imcc/main.c:581
It was re-entering Parrot_exit. Only now it was starting at exit_handler_list
*again*, which is now free()d memory. Crazy :-)
I've committed a fix.
However, this is only hiding the underlying bug, which is:
$ ./parrot t/pmc/objects_40.imc
ok 1
ok 2
ok 3
destroy() not implemented in class 'Integer'
(Failure on OS X. No failure on x86 Linux)
Nicholas Clark
