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
Comments
From @AlexDanielI am getting errors like: 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; my $response = run(:out, ‘curl’, ‘-s’, URL).out.slurp-rest; say ‘should've crashed before reaching this’; |
From @AlexDanielMaybe this can help: ==8544== On 2017-03-15 17:12:00, alex.jakimenko@gmail.com wrote:
|
From @jnthnOn Wed, 15 Mar 2017 20:30:28 -0700, alex.jakimenko@gmail.com wrote:
This is a read of memory during (or after) a native call.
But that was already freed...
...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. |
The RT System itself - Status changed from 'new' to 'open' |
From @AlexDanieldogbert17++ did a great job catching it under gdb: One: https://gist.github.com/dogbert17/ea5855ab29c74b1b518a9f86c2f24f62 To honest, these gists do not tell much to me… On 2017-03-19 06:23:14, jnthn@jnthn.net wrote:
|
From @SkarsnikLe Wed, 15 Mar 2017 17:12:00 -0700, alex.jakimenko@gmail.com a écrit :
I was not able to reproduce it on a 32bit Virtual Machine (debian stable) |
From @AlexDanielFWIW 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:
|
From @AlexDaniel I bisected it to rakudo/rakudo@40a953f Raku/nqp@2016.03-50-g512c9a1...2016.03-57-gbdb13a2 |
From @AlexDanielFWIW, still happens after all changes during this month. On 2017-07-22 16:21:30, alex.jakimenko@gmail.com wrote:
|
From @AlexDanielhttps://irclog.perlgeek.de/perl6-dev/2017-09-01#i_15102810 On 2017-07-31 08:27:09, alex.jakimenko@gmail.com wrote:
|
From @AlexDanielThere was a little bit of progress with this here: MoarVM/MoarVM#687 On 2017-09-01 12:53:36, alex.jakimenko@gmail.com wrote:
|
From @smlsWhat is the point of the `[ANNOYING]` tag? |
From @AlexDanielIn 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… 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:
|
From @ninerI 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. |
From @AlexDanielThis is fixed now: MoarVM/MoarVM#1119 |
@AlexDaniel - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#131003 (status was 'resolved')
Searchable as RT131003$
The text was updated successfully, but these errors were encountered: