Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The parrot crashes...

1 view
Skip to first unread message

Dan Sugalski

unread,
Jan 20, 2003, 2:09:10 PM1/20/03
to perl6-i...@perl.org
Rather badly, actually. All the tests that involve parrot currently
segfault in the NCI mark routine. At least on OS X, I'm not sure
about other platforms.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Leopold Toetsch

unread,
Jan 20, 2003, 5:54:03 PM1/20/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:

> Rather badly, actually. All the tests that involve parrot currently
> segfault in the NCI mark routine. At least on OS X, I'm not sure about
> other platforms.


Not on i386/Linux, anyway ...


Could be a slightly wrong init sequence, which I did introduce and have
hopefully fixed now.

When the commit cures the problem I have one addition, to (hopefully)
provoke such errors with --gc-debug.

leo

Leopold Toetsch

unread,
Jan 20, 2003, 6:27:44 PM1/20/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:

> Rather badly, actually. All the tests that involve parrot currently
> segfault in the NCI mark routine. At least on OS X, I'm not sure about
> other platforms.

Some questions WRT tinderboxen:
- above error seems currently not to be covered
- which machines are when reported/online (now only ~5)
- could we (people that wants to) have a *short* daily mail report like:

$arch compilerr warnings test failures
-----------------------------------------------
i386/linux 0 2 0
cray X1 4711 - -
...

Thanks,
leo


Josh Wilmes

unread,
Jan 20, 2003, 10:39:24 PM1/20/03
to Dan Sugalski, perl6-i...@perl.org

It appears to be the same thing for tcc and lcc on linux. The nearest I
can tell, the value stuffed into struct_val in Parrot_NCI_set_string_keyed
is somehow not a valid PObj- dereferencing its "obj" member seems to blow
things up.

It stomps all over the stack somehow, and I don't have much debugger mojo.

Plus, building with "-g" makes the problem go away. Bah.

--Josh

Blair Christensen

unread,
Jan 20, 2003, 3:14:13 PM1/20/03
to perl6-i...@perl.org
On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:
> Rather badly, actually. All the tests that involve parrot currently
> segfault in the NCI mark routine. At least on OS X, I'm not sure
> about other platforms.

5.8.0/Sparc64/OpenBSD is also rather unhappy.

I'm getting the following core dumps:
intlist_1.core intlist_3.core list_1.core parrot.core sprintf_2.core
intlist_2.core intlist_4.core list_2.core sprintf_1.core

parrot.core is the only one that seems to be having problems with
Parrot_NCI_mark, however.

% gdb -c parrot.core parrot
GNU gdb 4.16.1
This GDB was configured as "sparc64-unknown-openbsd3.1"
Core was generated by `parrot'.
Program terminated with signal 10, Bus error.
#0 0x1a8638 in pobject_lives ()
(gdb) bt
#0 0x1a8638 in pobject_lives ()
#1 0x1bcc78 in Parrot_NCI_mark ()
#2 0x1a8b88 in trace_active_PMCs ()
#3 0x1a9340 in Parrot_do_dod_run ()
#4 0x1a72c0 in more_traceable_objects ()
#5 0x1a73cc in get_free_object ()
#6 0x1a7a1c in get_free_buffer ()
#7 0x1a7f3c in new_bufferlike_header ()
#8 0x164354 in list_new ()
#9 0x1b2190 in Parrot_Array_init ()
#10 0x1663b0 in setup_argv ()
#11 0x166640 in Parrot_runcode ()
#12 0x1cdf98 in main ()
#13 0x11332c in ___start ()

blair.

Leopold Toetsch

unread,
Jan 21, 2003, 7:53:26 AM1/21/03
to blair christensen, perl6-i...@perl.org
blair christensen wrote:

> On Mon, Jan 20, 2003 at 02:09:10PM -0500, Dan Sugalski wrote:
>
>>Rather badly, actually. All the tests that involve parrot currently
>>segfault in the NCI mark routine. At least on OS X, I'm not sure
>>about other platforms.

> (gdb) bt


> #0 0x1a8638 in pobject_lives ()
> #1 0x1bcc78 in Parrot_NCI_mark ()


Is this with my patch (in CVS) already applied?


> blair.


leo


Blair Christensen

unread,
Jan 21, 2003, 2:33:54 PM1/21/03
to perl6-i...@perl.org

Yes.

I just did a realclean, cvs up, configure, make, and make test.

Lots of core files and as the last tinderbox report for this box
shows [0], a lot of failed tests. Parrot has never been completely
happy on this box but it seems to have taken a turn for the worse.

blair.

[0] <http://tinderbox.perl.org/tinderbox/showlog.cgi?log=parrot/1043172962.94137.gz&fulltext=1>

Simon Glover

unread,
Jan 21, 2003, 3:42:55 PM1/21/03
to Leopold Toetsch, perl6-i...@perl.org

Here's another data-point, for Linux/x86: with a fresh check-out, parrot
is passing all of its tests, but most of the imcc tests are failing.
Specifically, I get:

Failed Test Stat Wstat Total Fail Failed List of Failed
------------------------------------------------------------------
t/syn/clash.t 5 1280 5 5 100.00% 1-5
t/syn/const.t 3 768 3 3 100.00% 1-3
t/syn/eval.t 2 512 3 2 66.67% 1-2
t/syn/labels.t 3 768 3 3 100.00% 1-3
t/syn/namespace.t 3 768 3 3 100.00% 1-3
t/syn/scope.t 3 768 3 3 100.00% 1-3
1 subtest skipped.
Failed 6/9 test scripts, 33.33% okay. 19/24 subtests failed, 20.83% okay.

Closer examination suggests that all of these tests are failing because
imcc is sgefaulting; a representative backtrace is:

Program received signal SIGSEGV, Segmentation fault.
0x080dfb0a in pobject_lives ()
(gdb) bt
#0 0x080dfb0a in pobject_lives ()
#1 0x080ec252 in Parrot_NCI_mark ()
#2 0x080dfe94 in trace_active_PMCs ()
#3 0x080e03ac in Parrot_do_dod_run ()
#4 0x080e4cdd in more_traceable_objects ()
#5 0x080e4d7c in get_free_object ()
#6 0x080df260 in get_free_buffer ()
#7 0x080df61a in new_bufferlike_header ()
#8 0x080b60e3 in list_new ()
#9 0x080e51ff in Parrot_Array_init ()
#10 0x080b76ae in setup_argv ()
#11 0x080b7834 in Parrot_runcode ()
#12 0x0805693a in main ()

...which looks to be related to the problem people are encountering on
the other platforms.

Hope this is useful,
Simon


Leopold Toetsch

unread,
Jan 21, 2003, 6:14:32 PM1/21/03
to blair christensen, perl6-i...@perl.org, sc...@amnh.org
blair christensen wrote:

and Simon Glover reported:

>>>#0 0x1a8638 in pobject_lives ()
>>>#1 0x1bcc78 in Parrot_NCI_mark ()

I dunno yet, why mark is called with an uninitialized struct_val. The
mark function should only be called, if the corresponding flag is set.

For a first check, what's going on, I added init() again, which clears
struct_val.

I still don't understand, why NCI's mark is called. These objects are
only present in nci and (derived in) eval tests (and one pmc test or
so). Wrong object numbering or such, which "make realclean" (the
dependencies in the first place but, ...) should cope with.

Thanks for keekping on reporting this,
leo

Leopold Toetsch

unread,
Jan 21, 2003, 6:25:15 PM1/21/03
to blair christensen, perl6-i...@perl.org
blair christensen wrote:

>>>(gdb) bt
>>>#0 0x1a8638 in pobject_lives ()
>>>#1 0x1bcc78 in Parrot_NCI_mark ()

Just one thought:

before my eval patch PerlHash's enum was 12, what now NCI has.
From PMC.pm (now):

NCI => 12,
PerlArray => 13,
PerlHash => 14,
PerlInt => 15,

leo

0 new messages