Skip Menu |
Report information
Id: 131003
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alex.jakimenko [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [SEGV] Heap corruption when using Gumbo
Download (untitled) / with headers
text/plain 876b
I am getting errors like: MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to past fromspace MoarVM panic: Internal error: zeroed target thread ID in work pass Even though it happens when I'm using Gumbo module, my best guess is that it is not its fault. Does not crash that fast with 「perl6 --optimize=0 …」, but crashes anyway (you may want to bump up “^100” a little bit for this). Anyway, the code to replicate the issue is shown below. If it gets mangled for some reason, here is a mirror: https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f #!/usr/bin/env perl6 use Gumbo; constant URL = ‘https://perl6.org/community/’; my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest; for ^100 { .say for parse-html($response).root.elements(:TAG<a>, :RECURSE); } say ‘should've crashed before reaching this’;
Maybe this can help:

Show quoted text
==8544==
==8544== Invalid read of size 8
==8544==    at 0x4FD4B87: MVM_nativecall_refresh (nativecall.c:753)
==8544==    by 0x4FD6BCD: MVM_nativecall_invoke (nativecall_dyncall.c:780)
==8544==    by 0x4FAFECA: MVM_interp_run (interp.c:3994)
==8544==    by 0x5073838: MVM_vm_run_file (moar.c:310)
==8544==    by 0x109102: main (main.c:212)
==8544==  Address 0xca5c1a0 is 0 bytes inside a block of size 32 free'd
==8544==    at 0x4C2CDDB: free (vg_replace_malloc.c:530)
==8544==    by 0xD7729A0: gumbo_destroy_output (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
==8544==    by 0x507A2DC: ??? (in /home/alex/git/rakudo/install/lib/libmoar.so)
==8544==    by 0xFFEFFFB3F: ???
==8544==    by 0x507A215: dc_callvm_call_x64 (in /home/alex/git/rakudo/install/lib/libmoar.so)
==8544==    by 0xD77292F: ??? (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
==8544==    by 0xBEEA38F: ???
==8544==    by 0xBEEA38F: ???
==8544==    by 0xBEEA38F: ???
==8544==    by 0xFFEFFFB5F: ???
==8544==    by 0x5079B88: dcCallVoid (in /home/alex/git/rakudo/install/lib/libmoar.so)
==8544==    by 0xD77292F: ??? (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
==8544==  Block was alloc'd at
==8544==    at 0x4C2BBAF: malloc (vg_replace_malloc.c:299)
==8544==    by 0xD7719F7: gumbo_parse_with_options (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
==8544==    by 0x507A2DC: ??? (in /home/alex/git/rakudo/install/lib/libmoar.so)
==8544==    by 0xFFEFFFB3F: ???
==8544==    by 0x507A215: dc_callvm_call_x64 (in /home/alex/git/rakudo/install/lib/libmoar.so)
==8544==    by 0xD7728CF: ??? (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
==8544==    by 0xCA5A06F: ???
==8544==    by 0xCA5A06F: ???
==8544==    by 0xCA5A06F: ???
==8544==    by 0xFFEFFFB5F: ???
==8544==    by 0x5079D41: dcCallPointer (in /home/alex/git/rakudo/install/lib/libmoar.so)
==8544== by 0xD7728CF: ??? (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)



On 2017-03-15 17:12:00, alex.jakimenko@gmail.com wrote:
Show quoted text
> I am getting errors like:
> MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to past
> fromspace
> MoarVM panic: Internal error: zeroed target thread ID in work pass
>
> Even though it happens when I'm using Gumbo module, my best guess is
> that it is not its fault.
>
> Does not crash that fast with 「perl6 --optimize=0 …」, but crashes
> anyway (you may want to bump up “^100” a little bit for this).
>
> Anyway, the code to replicate the issue is shown below. If it gets
> mangled for some reason, here is a mirror:
> https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
>
> #!/usr/bin/env perl6
>
> use Gumbo;
> constant URL = ‘https://perl6.org/community/&rsquo;;
>
> my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> for ^100 {
> .say for parse-html($response).root.elements(:TAG<a>, :RECURSE);
> }
>
> say ‘should've crashed before reaching this’;


RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
On Wed, 15 Mar 2017 20:30:28 -0700, alex.jakimenko@gmail.com wrote: Show quoted text
> Maybe this can help: > > ==8544== > ==8544== Invalid read of size 8 > ==8544== at 0x4FD4B87: MVM_nativecall_refresh (nativecall.c:753) > ==8544== by 0x4FD6BCD: MVM_nativecall_invoke (nativecall_dyncall.c:780) > ==8544== by 0x4FAFECA: MVM_interp_run (interp.c:3994) > ==8544== by 0x5073838: MVM_vm_run_file (moar.c:310) > ==8544== by 0x109102: main (main.c:212)
This is a read of memory during (or after) a native call. Show quoted text
> ==8544== Address 0xca5c1a0 is 0 bytes inside a block of size 32 free'd
But that was already freed... Show quoted text
> ==8544== at 0x4C2CDDB: free (vg_replace_malloc.c:530) > ==8544== by 0xD7729A0: gumbo_destroy_output (in > /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0) > ==8544== by 0x507A2DC: ??? (in /home/alex/git/rakudo/install/lib/libmoar.so) > ==8544== by 0xFFEFFFB3F: ??? > ==8544== by 0x507A215: dc_callvm_call_x64 (in > /home/alex/git/rakudo/install/lib/libmoar.so) > ==8544== by 0xD77292F: ??? (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0) > ==8544== by 0xBEEA38F: ??? > ==8544== by 0xBEEA38F: ??? > ==8544== by 0xBEEA38F: ??? > ==8544== by 0xFFEFFFB5F: ??? > ==8544== by 0x5079B88: dcCallVoid (in > /home/alex/git/rakudo/install/lib/libmoar.so) > ==8544== by 0xD77292F: ??? (in /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
...by a call to gumbo_destroy_output, which is something that the module would have done explicitly. It's not impossible that it's a MoarVM bug, but this valgrind output looks as it would were the Gumbo module doing a use-after-free. If the problem can be caught under GDB then it may be possible to obtain a stacktrace (of the Perl 6 code) by using `p MVM_dump_backtrace(tc)`, which will show the Perl 6 call in question. Note, however, that the SEGV may happen far later than the point where valgrind detects things are wrong; http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver has some advice on using gdb and valgrind together.
dogbert17++ did a great job catching it under gdb:

One: https://gist.github.com/dogbert17/ea5855ab29c74b1b518a9f86c2f24f62
Two: https://gist.github.com/dogbert17/3eb15ea55019d93590e8ea1d4966f7b2

To honest, these gists do not tell much to me…


On 2017-03-19 06:23:14, jnthn@jnthn.net wrote:
Show quoted text
> On Wed, 15 Mar 2017 20:30:28 -0700, alex.jakimenko@gmail.com wrote:
> > Maybe this can help:
> >
> > ==8544==
> > ==8544== Invalid read of size 8
> > ==8544== at 0x4FD4B87: MVM_nativecall_refresh (nativecall.c:753)
> > ==8544== by 0x4FD6BCD: MVM_nativecall_invoke
> > (nativecall_dyncall.c:780)
> > ==8544== by 0x4FAFECA: MVM_interp_run (interp.c:3994)
> > ==8544== by 0x5073838: MVM_vm_run_file (moar.c:310)
> > ==8544== by 0x109102: main (main.c:212)
>
> This is a read of memory during (or after) a native call.
>
> > ==8544== Address 0xca5c1a0 is 0 bytes inside a block of size 32
> > free'd
>
> But that was already freed...
>
> > ==8544== at 0x4C2CDDB: free (vg_replace_malloc.c:530)
> > ==8544== by 0xD7729A0: gumbo_destroy_output (in
> > /usr/lib/x86_64-linux-gnu/libgumbo.so.1.0.0)
> > ==8544== by 0x507A2DC: ??? (in
> > /home/alex/git/rakudo/install/lib/libmoar.so)
> > ==8544== by 0xFFEFFFB3F: ???
> > ==8544== by 0x507A215: dc_callvm_call_x64 (in
> > /home/alex/git/rakudo/install/lib/libmoar.so)
> > ==8544== by 0xD77292F: ??? (in /usr/lib/x86_64-linux-
> > gnu/libgumbo.so.1.0.0)
> > ==8544== by 0xBEEA38F: ???
> > ==8544== by 0xBEEA38F: ???
> > ==8544== by 0xBEEA38F: ???
> > ==8544== by 0xFFEFFFB5F: ???
> > ==8544== by 0x5079B88: dcCallVoid (in
> > /home/alex/git/rakudo/install/lib/libmoar.so)
> > ==8544== by 0xD77292F: ??? (in /usr/lib/x86_64-linux-
> > gnu/libgumbo.so.1.0.0)
>
> ...by a call to gumbo_destroy_output, which is something that the
> module would have done explicitly.
>
> It's not impossible that it's a MoarVM bug, but this valgrind output
> looks as it would were the Gumbo module doing a use-after-free.
>
> If the problem can be caught under GDB then it may be possible to
> obtain a stacktrace (of the Perl 6 code) by using `p
> MVM_dump_backtrace(tc)`, which will show the Perl 6 call in question.
> Note, however, that the SEGV may happen far later than the point where
> valgrind detects things are wrong;
> http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-
> adv.gdbserver has some advice on using gdb and valgrind together.


Download (untitled) / with headers
text/plain 1.1k
Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a écrit : Show quoted text
> I am getting errors like: > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to past > fromspace > MoarVM panic: Internal error: zeroed target thread ID in work pass > > Even though it happens when I'm using Gumbo module, my best guess is > that it is not its fault. > > Does not crash that fast with 「perl6 --optimize=0 …」, but crashes > anyway (you may want to bump up “^100” a little bit for this). > > Anyway, the code to replicate the issue is shown below. If it gets > mangled for some reason, here is a mirror: > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f > > #!/usr/bin/env perl6 > > use Gumbo; > constant URL = ‘https://perl6.org/community/’; > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest; > for ^100 { > .say for parse-html($response).root.elements(:TAG<a>, :RECURSE); > } > > say ‘should've crashed before reaching this’;
I was not able to reproduce it on a 32bit Virtual Machine (debian stable) Using 2016.11 rakudo and the latest from git. Maybe it can be related to how struct size are determined by MoarVM.
FWIW the problem is still there and is reproducible with the provided snippet (just in case somebody is wondering if the issue went away by itself after these months).

On 2017-04-04 06:46:20, scolinet@gmail.com wrote:
Show quoted text
> Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a écrit :
> > I am getting errors like:
> > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to past
> > fromspace
> > MoarVM panic: Internal error: zeroed target thread ID in work pass
> >
> > Even though it happens when I'm using Gumbo module, my best guess is
> > that it is not its fault.
> >
> > Does not crash that fast with 「perl6 --optimize=0 …」, but crashes
> > anyway (you may want to bump up “^100” a little bit for this).
> >
> > Anyway, the code to replicate the issue is shown below. If it gets
> > mangled for some reason, here is a mirror:
> > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> >
> > #!/usr/bin/env perl6
> >
> > use Gumbo;
> > constant URL = ‘https://perl6.org/community/&rsquo;;
> >
> > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > for ^100 {
> > .say for parse-html($response).root.elements(:TAG<a>, :RECURSE);
> > }
> >
> > say ‘should've crashed before reaching this’;
>
> I was not able to reproduce it on a 32bit Virtual Machine (debian stable)
> Using 2016.11 rakudo and the latest from git.
> Maybe it can be related to how struct size are determined by MoarVM.
>


I bisected it to https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000

On earlier rakudo versions it seems to be working fine. I haven't seen it crash once on anything earlier, but it is *very* slow on rakudos that old, so it's hard to tell.

nqp changes:

https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-57-gbdb13a2

moar changes:
https://github.com/MoarVM/MoarVM/compare/2016.03-84-g4afd7b6...2016.03-104-g10d3971

On 2017-05-13 17:00:08, alex.jakimenko@gmail.com wrote:
> FWIW the problem is still there and is reproducible with the provided
> snippet
> (just in case somebody is wondering if the issue went away by itself
> after
> these months).
>
> On 2017-04-04 06:46:20, scolinet@gmail.com wrote:
> > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a écrit
> > :
> > > I am getting errors like:
> > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to
> > > past
> > > fromspace
> > > MoarVM panic: Internal error: zeroed target thread ID in work pass
> > >
> > > Even though it happens when I'm using Gumbo module, my best guess
> > > is
> > > that it is not its fault.
> > >
> > > Does not crash that fast with 「perl6 --optimize=0 …」, but crashes
> > > anyway (you may want to bump up “^100” a little bit for this).
> > >
> > > Anyway, the code to replicate the issue is shown below. If it gets
> > > mangled for some reason, here is a mirror:
> > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > >
> > > #!/usr/bin/env perl6
> > >
> > > use Gumbo;
> > > constant URL = ‘https://perl6.org/community/&rsquo;;
> > >
> > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > for ^100 {
> > > .say for parse-html($response).root.elements(:TAG<a>, :RECURSE);
> > > }
> > >
> > > say ‘should've crashed before reaching this’;
> >
> > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > stable)
> > Using 2016.11 rakudo and the latest from git.
> > Maybe it can be related to how struct size are determined by MoarVM.
> >


 

FWIW, still happens after all changes during this month.

On 2017-07-22 16:21:30, alex.jakimenko@gmail.com wrote:
Show quoted text
> I bisected it to
> https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
>
> On earlier rakudo versions it seems to be working fine. I haven't seen
> it crash
> once on anything earlier, but it is *very* slow on rakudos that old,
> so it's
> hard to tell.
>
> nqp changes:
>
> https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-57-
> gbdb13a2
>
> moar changes:
> https://github.com/MoarVM/MoarVM/compare/2016.03-84-
> g4afd7b6...2016.03-104-g10d3971
>
> On 2017-05-13 17:00:08, alex.jakimenko@gmail.com wrote:
> > FWIW the problem is still there and is reproducible with the provided
> > snippet
> > (just in case somebody is wondering if the issue went away by itself
> > after
> > these months).
> >
> > On 2017-04-04 06:46:20, scolinet@gmail.com wrote:
> > > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a
> > > écrit
> > > :
> > > > I am getting errors like:
> > > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588 to
> > > > past
> > > > fromspace
> > > > MoarVM panic: Internal error: zeroed target thread ID in work
> > > > pass
> > > >
> > > > Even though it happens when I'm using Gumbo module, my best guess
> > > > is
> > > > that it is not its fault.
> > > >
> > > > Does not crash that fast with 「perl6 --optimize=0 …」, but crashes
> > > > anyway (you may want to bump up “^100” a little bit for this).
> > > >
> > > > Anyway, the code to replicate the issue is shown below. If it
> > > > gets
> > > > mangled for some reason, here is a mirror:
> > > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > > >
> > > > #!/usr/bin/env perl6
> > > >
> > > > use Gumbo;
> > > > constant URL = ‘https://perl6.org/community/&rsquo;;
> > > >
> > > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > > for ^100 {
> > > > .say for parse-html($response).root.elements(:TAG<a>, :RECURSE);
> > > > }
> > > >
> > > > say ‘should've crashed before reaching this’;
> > >
> > > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > > stable)
> > > Using 2016.11 rakudo and the latest from git.
> > > Maybe it can be related to how struct size are determined by
> > > MoarVM.
> > >


https://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810

On 2017-07-31 08:27:09, alex.jakimenko@gmail.com wrote:
Show quoted text
> FWIW, still happens after all changes during this month.
>
> On 2017-07-22 16:21:30, alex.jakimenko@gmail.com wrote:
> > I bisected it to
> >
> https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
> >
> > On earlier rakudo versions it seems to be working fine. I haven't
> > seen
> > it crash
> > once on anything earlier, but it is *very* slow on rakudos that old,
> > so it's
> > hard to tell.
> >
> > nqp changes:
> >
> > https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-
> > 57-
> > gbdb13a2
> >
> > moar changes:
> > https://github.com/MoarVM/MoarVM/compare/2016.03-84-
> > g4afd7b6...2016.03-104-g10d3971
> >
> > On 2017-05-13 17:00:08, alex.jakimenko@gmail.com wrote:
> > > FWIW the problem is still there and is reproducible with the
> > > provided
> > > snippet
> > > (just in case somebody is wondering if the issue went away by
> > > itself
> > > after
> > > these months).
> > >
> > > On 2017-04-04 06:46:20, scolinet@gmail.com wrote:
> > > > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a
> > > > écrit
> > > > :
> > > > > I am getting errors like:
> > > > > MoarVM panic: Heap corruption detected: pointer 0x7f9a96a5e588
> > > > > to
> > > > > past
> > > > > fromspace
> > > > > MoarVM panic: Internal error: zeroed target thread ID in work
> > > > > pass
> > > > >
> > > > > Even though it happens when I'm using Gumbo module, my best
> > > > > guess
> > > > > is
> > > > > that it is not its fault.
> > > > >
> > > > > Does not crash that fast with 「perl6 --optimize=0 …」, but
> > > > > crashes
> > > > > anyway (you may want to bump up “^100” a little bit for this).
> > > > >
> > > > > Anyway, the code to replicate the issue is shown below. If it
> > > > > gets
> > > > > mangled for some reason, here is a mirror:
> > > > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > > > >
> > > > > #!/usr/bin/env perl6
> > > > >
> > > > > use Gumbo;
> > > > > constant URL = ‘https://perl6.org/community/&rsquo;;
> > > > >
> > > > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > > > for ^100 {
> > > > > .say for parse-html($response).root.elements(:TAG<a>,
> > > > > :RECURSE);
> > > > > }
> > > > >
> > > > > say ‘should've crashed before reaching this’;
> > > >
> > > > I was not able to reproduce it on a 32bit Virtual Machine (debian
> > > > stable)
> > > > Using 2016.11 rakudo and the latest from git.
> > > > Maybe it can be related to how struct size are determined by
> > > > MoarVM.
> > > >


There was a little bit of progress with this here: https://github.com/MoarVM/MoarVM/pull/687

On 2017-09-01 12:53:36, alex.jakimenko@gmail.com wrote:
Show quoted text
> https://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810
>
> On 2017-07-31 08:27:09, alex.jakimenko@gmail.com wrote:
> > FWIW, still happens after all changes during this month.
> >
> > On 2017-07-22 16:21:30, alex.jakimenko@gmail.com wrote:
> > > I bisected it to
> > >
> >
> https://github.com/rakudo/rakudo/commit/40a953f5d9f5c661d8cf9b043643002d348a2000
> > >
> > > On earlier rakudo versions it seems to be working fine. I haven't
> > > seen
> > > it crash
> > > once on anything earlier, but it is *very* slow on rakudos that
> > > old,
> > > so it's
> > > hard to tell.
> > >
> > > nqp changes:
> > >
> > > https://github.com/perl6/nqp/compare/2016.03-50-g512c9a1...2016.03-
> > > 57-
> > > gbdb13a2
> > >
> > > moar changes:
> > > https://github.com/MoarVM/MoarVM/compare/2016.03-84-
> > > g4afd7b6...2016.03-104-g10d3971
> > >
> > > On 2017-05-13 17:00:08, alex.jakimenko@gmail.com wrote:
> > > > FWIW the problem is still there and is reproducible with the
> > > > provided
> > > > snippet
> > > > (just in case somebody is wondering if the issue went away by
> > > > itself
> > > > after
> > > > these months).
> > > >
> > > > On 2017-04-04 06:46:20, scolinet@gmail.com wrote:
> > > > > Le Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a
> > > > > écrit
> > > > > :
> > > > > > I am getting errors like:
> > > > > > MoarVM panic: Heap corruption detected: pointer
> > > > > > 0x7f9a96a5e588
> > > > > > to
> > > > > > past
> > > > > > fromspace
> > > > > > MoarVM panic: Internal error: zeroed target thread ID in work
> > > > > > pass
> > > > > >
> > > > > > Even though it happens when I'm using Gumbo module, my best
> > > > > > guess
> > > > > > is
> > > > > > that it is not its fault.
> > > > > >
> > > > > > Does not crash that fast with 「perl6 --optimize=0 …」, but
> > > > > > crashes
> > > > > > anyway (you may want to bump up “^100” a little bit for
> > > > > > this).
> > > > > >
> > > > > > Anyway, the code to replicate the issue is shown below. If it
> > > > > > gets
> > > > > > mangled for some reason, here is a mirror:
> > > > > > https://gist.github.com/AlexDaniel/ac7a4d4c49ec8d23e546529976dda67f
> > > > > >
> > > > > > #!/usr/bin/env perl6
> > > > > >
> > > > > > use Gumbo;
> > > > > > constant URL = ‘https://perl6.org/community/&rsquo;;
> > > > > >
> > > > > > my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest;
> > > > > > for ^100 {
> > > > > > .say for parse-html($response).root.elements(:TAG<a>,
> > > > > > :RECURSE);
> > > > > > }
> > > > > >
> > > > > > say ‘should've crashed before reaching this’;
> > > > >
> > > > > I was not able to reproduce it on a 32bit Virtual Machine
> > > > > (debian
> > > > > stable)
> > > > > Using 2016.11 rakudo and the latest from git.
> > > > > Maybe it can be related to how struct size are determined by
> > > > > MoarVM.
> > > > >


What is the point of the `[ANNOYING]` tag? All bugs are probably annoying to *someone*...
In this particular case it means you cannot write web scrapers using rakudo. And not only that, but it makes you feel like rakudo is completely broken if it can't even go through a few tens of pages without SEGV-ing. If Skarsnik's suspicion that the issue is in XML right, then it's not just with gumbo but with any module using XML module for serious work.

Not all bugs are annoying. Anything that errors out during the compilation is not [ANNOYING] because the issue just jumps right at you. Anything that has a workaround is probably not [ANNOYING] because there's a way to deal with the issue. For example, in this case:

* It doesn't SEGV for the first few pages you scrape, so before you know about this ticket you'll probably proceed with whatever you're doing… and in the end when you start doing your almost-production runs you'll realize that it doesn't work and it won't work ever, no matter what you do because…
* There's no reasonable workaround. The only thing I've come up with is using python-gumbo through Inline::Python so that's what I am doing sometimes. It's horrible. And yes you'll have to rewrite the whole thing.

I've introduced the [ANNOYING] tag very recently, so there's no comprehensive list yet. But take a look at https://fail.rakudo.party/t/ANNOYING for some examples. Most of these create “rakudo sucks” impression and have no reasonable workarounds. But I haven't thought about the actual criteria yet.

On 2017-10-04 12:38:26, smls75@gmail.com wrote:
Show quoted text
> What is the point of the `[ANNOYING]` tag?
> All bugs are probably annoying to *someone*...



This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org