Parrot Segfault
Matt Fowles
Although all tests pass, a core file is created during the test run.
Here is a little snippet from GDB. I am running a fairly stock Debian
Testing x86 (slightly out of date).
(gdb) list
1006 INTVAL
1007 PIO_putps(theINTERP, PMC *pmc, STRING *s)
1008 {
1009 ParrotIOLayer *l = PMC_struct_val(pmc);
1010 ParrotIO *io = PMC_data0(pmc);
1011 assert((unsigned int)l != 0xdeadbeefU);
1012 assert(io != 0);
1013 return PIO_write_down(interpreter, l, io, s);
1014 }
1015
(gdb) p l
$1 = (ParrotIOLayer *) 0xdeadbeef
(gdb) bt
#0 0x4020e741 in kill () from /usr/lib/debug/libc.so.6
#1 0x40024771 in pthread_kill (thread=595, signo=0) at signals.c:65
#2 0x40024a7b in __pthread_raise (sig=1073917184) at signals.c:187
#3 0x4020e4d4 in *__GI_raise (sig=6) at
../linuxthreads/sysdeps/unix/sysv/linux/raise.c:34
#4 0x4020fa08 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#5 0x40207b3f in *__GI___assert_fail (assertion=0x0, file=0x0,
line=0, function=0x8219864 "PIO_putps") at assert.c:83
#6 0x08128193 in PIO_putps (interpreter=0x826e050, pmc=0x82a93e8,
s=0x843c7d8) at io/io.c:1011
#7 0x080e9c67 in Parrot_print_p_sc (cur_opcode=0x84d837c,
interpreter=0x826e050) at io.ops:308
#8 0x08158aa0 in runops_slow_core (interpreter=0x826e050,
pc=0x84d837c) at src/runops_cores.c:153
#9 0x08156f0d in runops_int (interpreter=0x826e050, offset=0) at
src/interpreter.c:750
#10 0x08157de5 in runops (interpreter=0x826e050, offs=0) at src/inter_run.c:81
#11 0x080c3031 in Parrot_runcode (interpreter=0x826e050, argc=1,
argv=0xbffff8ac) at src/embed.c:831
#12 0x080c2e72 in Parrot_runcode (interpreter=0x826e050, argc=1,
argv=0xbffff8ac) at src/embed.c:765
#13 0x0808588e in main (argc=1, argv=0xbffff8ac) at imcc/main.c:637
Thanks,
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Jens Rieks
print ((char**)0xbffff8ac)[1]
to find out which file causes the coredump??
jens
Matt Fowles
Sure!
> gdb ./parrot core
<snip/>
Core was generated by `./parrot --gc-debug
/home/mfowles/perl6/parrot/t/pmc/io_1.pir'.
Program terminated with signal 6, Aborted.
<snip/>
(gdb) print ((char**)0xbffff8ac)[0]
$3 = 0xbffff9ee "/home/mfowles/perl6/parrot/t/pmc/io_1.pir"
(gdb) print ((char**)0xbffff8ac)[1]
$4 = 0x0
Hope that helps,
Leopold Toetsch
> Core was generated by `./parrot --gc-debug
> /home/mfowles/perl6/parrot/t/pmc/io_1.pir'.
Ah. ok. That's a TODO tests that is supposed to fail. It is testing io
opcodes with undefs and integer PMCs.
As soon as the io opcodes are methods in ParrotIO we get type safety and
appropriate error messages.
leo
Matt Fowles
Would it be reasonable to not run tests that are known to leave core
files? I feel like after a successful build there should not be
evidence like this left around...
Jens Rieks
> t/pmc/io_1.pir
Ah, yes. This is a failing todo test. The useage of IO ops on non IO-PMCs is
not specced yet.
jens
#6 0x08128193 in PIO_putps (interpreter=0x826e050, pmc=0x82a93e8,
s=0x843c7d8) at io/io.c:1011
1006 INTVAL
1007 PIO_putps(theINTERP, PMC *pmc, STRING *s)
1008 {
PMC_struct_val is not a valid ParrotIOLayer for non PIO-PMCs:
1009 ParrotIOLayer *l = PMC_struct_val(pmc);
1010 ParrotIO *io = PMC_data0(pmc);
The next assertion fails in most (but not all) cases:
Chromatic
> Would it be reasonable to not run tests that are known to leave core
> files? I feel like after a successful build there should not be
> evidence like this left around...
People could set ulimit (though we'd have to tell them all to do that)
or Parrot::Test could have an END block that removes all core.* files
unless an environment variable is set.
-- c
Nicholas Clark
You're making an assumption here about the name of core files, and where they
are located.
(Although setting ulimit -c above 0 on OS X is painful, given the size of
the core files generated. So it's unlikely that parrot will be writing into
/cores/ )
Nicholas Clark