On Wed, 15 Mar 2017 20:30:28 -0700, alex.jakime...@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.
