Stability, complexity bottlenecks
Carl Mäsak
building code by the following steps:
$ git clone git://github.com/masak/gge.git
$ cd gge
$ export PERL6LIB=`pwd`/lib
$ git co -b exhandler-failure origin/exhandler-failure
$ perl6 Configure
$ make
The following blows up on my system:
$ perl6 t/perl6regex/01-regex.t
ok 1 - [quantifiers:1] star 2+
ok 2 - [quantifiers:2] star 1
ok 3 - [quantifiers:3] star 0
ok 4 - [quantifiers:4] star 2+
ok 5 - [quantifiers:5] star 1
ok 6 - [quantifiers:6] star 0
** Exception caught while looking for a handler, trying next **
** Exception caught while looking for a handler, trying next **
get_iter() not implemented in class 'Integer'
current instr.: 'take' pc 16710 (src/builtins/control.pir:82)
called from Sub '(null)' pc -1 ((unknown file):-1)Segmentation fault
(Sometimes I get the error messages and then the segfault, sometimes I get
just the segfault.)
GGE has ~1k LOC. (Compare this to November's ~1.6k LOC.) It's at the upper
range of the spectrum of Perl 6 application sizes, and it also creates a
fair amount of objects as it runs. I keep getting failures such as the
above about every 20 h of coding. Usually they go away pretty easily, just
by my changing a character somewhere in the source. I've never tried to
isolate a failure of this sort, because due to their instability, I don't
really know how I'd go about it. They are, however, 'stable' in the sense that
if I run things repeatedly without any changes, the failure occurs in the
same place each time.
I have a few questions:
* How can I, as a motivated Rakudo application developer, help make Parrot
more stable when something like this occurs in my app? In Rakudo, I can
minimize the failure to a line or two, and the devs have a much easier
time fixing the failures. Here, it seems that the cause of the failure is
the complexity of the app, and thus not reducible to a minimal case.
I know how relatively unhelpful instructions like "build my app and make it
do this" are, compared to "this 10-line PIR file causes problems".
* Are bug reports on these kinds of failures useful? They seem transient,
and go away when conditions change slightly. Often people on other
platforms cannot reproduce them. Somehow, the errors themselves are not
the problem, but the underlying cause which makes them come and go on
a regular basis.
* Is there a plan to eradicate or greatly reduce failures like these by
Parrot 2.0? If so, is there any way I can help? I fear the day might come
when one of these errors prevents me from developing my app, and I'd
like to pre-empt that.
I'd love to see these random stability problems related to complexity
bottlenecks go away completely -before- Parrot/Rakudo reach sufficient
traction that other people try to develop applications with the size
and memory usage that makes the current problems manifest themselves.
// Carl
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Moritz Lenz
> GGE has ~1k LOC. (Compare this to November's ~1.6k LOC.) It's at the upper
> range of the spectrum of Perl 6 application sizes, and it also creates a
> fair amount of objects as it runs. I keep getting failures such as the
> above about every 20 h of coding. Usually they go away pretty easily, just
> by my changing a character somewhere in the source. I've never tried to
> isolate a failure of this sort, because due to their instability, I don't
> really know how I'd go about it. They are, however, 'stable' in the sense that
> if I run things repeatedly without any changes, the failure occurs in the
> same place each time.
There are easier ways to observe segfaults in Rakudo+Parrot that might
belong in the same category. For example the mandelbrot scripts from
http://github.com/colomon/mandelbrot
$ perl6 mandelbrot-color.pl 71 > /dev/null
Segmentation fault
This is only about 250 lines of code, and does nothing fancy: subroutine
calls, arithmetics, a bit of control flow. It just runs quite many of
these operations, the command line argument controls how many.
For some sizes it segfaults reproducible, for others (even larger
numbers) it succeeds,
As an incentive to fix it: You can redirect the output into a .pnm file
and get a pretty picture if it actually succeeds :-)
I'd also like to know if other HLL developers and users see similar
problems, or if it's specific to Rakudo.
Cheers,
Moritz
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Andy Dougherty
> With Parrot r43112 and Rakudo 8dc189 installed, after downloading and
> building code by the following steps:
>
> $ git clone git://github.com/masak/gge.git
> $ cd gge
> $ export PERL6LIB=`pwd`/lib
> $ git co -b exhandler-failure origin/exhandler-failure
> $ perl6 Configure
I tried to reproduce this problem, but I got stuck at this step, with
Configure.pm is preparing to make your Makefile.
Found a PARROT_DIR to be /home/doughera/tmp/parrot
but there is no Rakudo nearby. Please contact the proto people.
I had built and installed a parrot, and then used that to build and
install a rakudo. I guess that's not supported.
--
Andy Dougherty doug...@lafayette.edu
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Andy Dougherty
> There are easier ways to observe segfaults in Rakudo+Parrot that might
> belong in the same category. For example the mandelbrot scripts from
> http://github.com/colomon/mandelbrot
>
> $ perl6 mandelbrot-color.pl 71 > /dev/null
> Segmentation fault
>
> This is only about 250 lines of code, and does nothing fancy: subroutine
> calls, arithmetics, a bit of control flow. It just runs quite many of
> these operations, the command line argument controls how many.
I clicked on the 'download' link there and tried that, but my copy is only
about 30 lines of code, doesn't segfault, and the '71' parameter doesn't
do anything. I suspect github isn't serving up what you're working with.
Moritz Lenz
> On Mon, 21 Dec 2009, Moritz Lenz wrote:
>
>> There are easier ways to observe segfaults in Rakudo+Parrot that might
>> belong in the same category. For example the mandelbrot scripts from
>> http://github.com/colomon/mandelbrot
>>
>> $ perl6 mandelbrot-color.pl 71 > /dev/null
>> Segmentation fault
>>
>> This is only about 250 lines of code, and does nothing fancy: subroutine
>> calls, arithmetics, a bit of control flow. It just runs quite many of
>> these operations, the command line argument controls how many.
>
> I clicked on the 'download' link there and tried that, but my copy is only
> about 30 lines of code, doesn't segfault, and the '71' parameter doesn't
> do anything. I suspect github isn't serving up what you're working with.
Please try it again with:
http://github.com/colomon/mandelbrot/raw/master/mandelbrot-color.pl
Sorry for being less specific the last time.
Jonathan Leto
[snip]
>
> I have a few questions:
>
> * How can I, as a motivated Rakudo application developer, help make Parrot
> more stable when something like this occurs in my app? In Rakudo, I can
> minimize the failure to a line or two, and the devs have a much easier
> time fixing the failures. Here, it seems that the cause of the failure is
> the complexity of the app, and thus not reducible to a minimal case.
> I know how relatively unhelpful instructions like "build my app and make it
> do this" are, compared to "this 10-line PIR file causes problems".
Please let us know when you run into these problems, we might be able
to tell you something like
"hey a branch just got merged that may be causing some funny business"
or something like that. If
you can bisect the Parrot commit that makes things go wonky, that
would be even better. You can
use the parrot github mirror [0] to do a git bisect, although you can
do svn bisects, they are painfully slow.
>
> * Are bug reports on these kinds of failures useful? They seem transient,
> and go away when conditions change slightly. Often people on other
> platforms cannot reproduce them. Somehow, the errors themselves are not
> the problem, but the underlying cause which makes them come and go on
> a regular basis.
Yes, they are useful. Your application is large enough to find bugs
that we have not written tests for yet.
So when we merge a branch, patting ourselves on the back that our test
suite still passes, sometimes HLL devs get the short end of that
stick. You are most likely getting bit by changes to our calling
conventions and/or tickling bugs in our GC that we haven't run into
yet or a combination of both.
>
> * Is there a plan to eradicate or greatly reduce failures like these by
> Parrot 2.0? If so, is there any way I can help? I fear the day might come
> when one of these errors prevents me from developing my app, and I'd
> like to pre-empt that.
Please tell us whenever you feel that you are getting bit by a Parrot
bug, our wish is that 2.0 be as stable and fast as possible. No big
new features are planned before 2.0, just writing more tests, fixing
bugs, improving docs and perhaps a few performance tweaks. We want 2.0
to be a solid base for Rakudo Star, but I think under the current
plan, 2.3 will be a supported release and that is probably what Rakudo
Star will be targeting.
>
> I'd love to see these random stability problems related to complexity
> bottlenecks go away completely -before- Parrot/Rakudo reach sufficient
> traction that other people try to develop applications with the size
> and memory usage that makes the current problems manifest themselves.
I heartily agree. The more Rakudo and Parrot can help each other, the
closer to that vision we will be.
Duke
>
> // Carl
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
--
Jonathan "Duke" Leto
jona...@leto.net
http://leto.net
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Jonathan Leto
I forgot to give the link for the Parrot github repo:
Make sure to use the 'upstream' branch, which is a pure mirror of
Parrot svn trunk, with no additional merge commits.
Duke
Carl Mäsak
>> With Parrot r43112 and Rakudo 8dc189 installed, after downloading and
>> building code by the following steps:
>>
>> $ git clone git://github.com/masak/gge.git
>> $ cd gge
>> $ export PERL6LIB=`pwd`/lib
>> $ git co -b exhandler-failure origin/exhandler-failure
>> $ perl6 Configure
>
> I tried to reproduce this problem, but I got stuck at this step, with
>
> Configure.pm is preparing to make your Makefile.
>
> Found a PARROT_DIR to be /home/doughera/tmp/parrot
> but there is no Rakudo nearby. Please contact the proto people.
>
> I had built and installed a parrot, and then used that to build and
> install a rakudo. I guess that's not supported.
Hello, proto person here. Yes, you seem to be running a setup that
Configure.pm currently doesn't support.
If you can stomach the hackishness of it all, could you try editing
lib/Configure.pm, hardcoding your Rakudo path on line 16, and then
commenting our lines 23-38? That should get you moving again.
Andy Dougherty
> > I clicked on the 'download' link there and tried that, but my copy is only
> > about 30 lines of code, doesn't segfault, and the '71' parameter doesn't
> > do anything. I suspect github isn't serving up what you're working with.
>
> Please try it again with:
>
> http://github.com/colomon/mandelbrot/raw/master/mandelbrot-color.pl
>
> Sorry for being less specific the last time.
Thanks. I will try that next time I have an opportunity.
Andy Dougherty
> If you can stomach the hackishness of it all, could you try editing
> lib/Configure.pm, hardcoding your Rakudo path on line 16, and then
> commenting our lines 23-38? That should get you moving again.
Thanks. I will try that next time I have a chance.