Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heap corruption when using Gumbo #6134

Closed
p6rt opened this issue Mar 16, 2017 · 16 comments
Closed

Heap corruption when using Gumbo #6134

p6rt opened this issue Mar 16, 2017 · 16 comments

Comments

@p6rt
Copy link

@p6rt p6rt commented Mar 16, 2017

Migrated from rt.perl.org#131003 (status was 'resolved')

Searchable as RT131003$

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 16, 2017

From @AlexDaniel

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’;

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 16, 2017

From @AlexDaniel

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)
==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​:

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’;

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 19, 2017

From @jnthn

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 19, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

@p6rt p6rt commented Mar 28, 2017

From @AlexDaniel

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​:

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Apr 4, 2017

From @Skarsnik

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/’;

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.

@p6rt
Copy link
Author

@p6rt p6rt commented May 14, 2017

From @AlexDaniel

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/’;

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 22, 2017

From @AlexDaniel

  I bisected it to rakudo/rakudo@40a953f
 
  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​:

  Raku/nqp@2016.03-50-g512c9a1...2016.03-57-gbdb13a2
 
  moar changes​:
  MoarVM/MoarVM@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/’;
  > > >
  > > > 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.
  > >
 
 
   

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 31, 2017

From @AlexDaniel

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
rakudo/rakudo@40a953f

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​:

Raku/nqp@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/’;

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Sep 1, 2017

From @AlexDaniel

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

rakudo/rakudo@40a953f

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​:

Raku/nqp@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/’;

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Sep 18, 2017

From @AlexDaniel

There was a little bit of progress with this here​: MoarVM/MoarVM#687

On 2017-09-01 12​:53​:36, alex.jakimenko@​gmail.com wrote​:

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

rakudo/rakudo@40a953f

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​:

Raku/nqp@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/’;

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.

@p6rt
Copy link
Author

@p6rt p6rt commented Oct 4, 2017

From @smls

What is the point of the `[ANNOYING]` tag?
All bugs are probably annoying to *someone*...

@p6rt
Copy link
Author

@p6rt p6rt commented Oct 5, 2017

From @AlexDaniel

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​:

What is the point of the `[ANNOYING]` tag?
All bugs are probably annoying to *someone*...

@p6rt
Copy link
Author

@p6rt p6rt commented Aug 11, 2018

From @niner

I patched Gumbo to no longer create an XML tree but just a bunch of hashes, yet the error remains. So it's clearly not the XML module causing the issue but some NativeCall Gumbo thing. Gumbo makes heavy use of structs and nested structs. I guess the latter could be worth having a look as that's something that probably hasn't seen much use yet.

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 9, 2019

From @AlexDaniel

This is fixed now​: MoarVM/MoarVM#1119

@p6rt
Copy link
Author

@p6rt p6rt commented Jul 9, 2019

@AlexDaniel - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant