Parrot Segfault

0 views
Skip to first unread message

Matt Fowles

unread,
Jun 28, 2005, 3:50:50 PM6/28/05
to perl6-i...@perl.org
All~

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."
-???

myconfig

Jens Rieks

unread,
Jun 29, 2005, 7:54:19 AM6/29/05
to Matt Fowles, perl6-i...@perl.org
> #13 0x0808588e in main (argc=1, argv=0xbffff8ac) at imcc/main.c:637
Can you please run
print ((char**)0xbffff8ac)[1]
to find out which file causes the coredump??

jens

Matt Fowles

unread,
Jun 29, 2005, 9:24:47 AM6/29/05
to Jens Rieks, perl6-i...@perl.org
Jens~

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

unread,
Jun 29, 2005, 10:41:32 AM6/29/05
to Matt Fowles, Jens Rieks, perl6-i...@perl.org
Matt Fowles wrote:

> 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

unread,
Jun 29, 2005, 10:59:59 AM6/29/05
to Leopold Toetsch, Jens Rieks, perl6-i...@perl.org
Leo~

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

unread,
Jun 29, 2005, 10:56:00 AM6/29/05
to Matt Fowles, perl6-i...@perl.org
On Wednesday 29 June 2005 15:24, Matt Fowles wrote:
> 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

unread,
Jun 29, 2005, 11:37:44 AM6/29/05
to Matt Fowles, p6i
On Wed, 2005-06-29 at 10:59 -0400, Matt Fowles wrote:

> 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

unread,
Jul 1, 2005, 5:33:05 AM7/1/05
to chromatic, Matt Fowles, p6i

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

Reply all
Reply to author
Forward
0 new messages