On Sat, 01 Oct 2016 11:42:20 -0700, nicholas wrote: > On Sat, Oct 01, 2016 at 08:14:16AM -0700, Daniel Green wrote: > > # New Ticket Created by Daniel Green > > # Please include the string: [perl #129781] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org/Ticket/Display.html?id=129781 > > > > > > > await (for ^7 { start ‘/etc/hostname’.IO ~~ :e }) > > > > regular perl6-valgrind-m output here: > > https://gist.github.com/MasterDuke17/9ab9ec5bdbc483bfe63213bf26f82316 > > Nice catch. ASAN has fun: > > $ ./perl6-m -Ilib -e 'await (for ^7 { start ‘/etc/hostname’.IO ~~ :e > })' > ================================================================= > ==9674==ERROR: AddressSanitizer: attempting double-free on > 0x603000381040 in thread T4: > #0 0x7fb46d651417 in __interceptor_free > ../../.././libsanitizer/asan/asan_malloc_linux.cc:62 > #1 0x7fb46cc99075 in MVM_free src/core/alloc.h:29 > #2 0x7fb46cca388b in MVM_string_flatten src/strings/ops.c:1241 > #3 0x7fb46ca027ef in MVM_interp_run src/core/interp.c:1601 > #4 0x7fb46ca9776a in start_thread src/core/threads.c:77 > #5 0x7fb46cd6152d in uv__thread_start > 3rdparty/libuv/src/unix/thread.c:49 > #6 0x7fb46bdcfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0) > #7 0x7fb46c2d5aac in __clone (/lib64/libc.so.6+0xe8aac) > > 0x603000381040 is located 0 bytes inside of 24-byte region > [0x603000381040,0x603000381058) > freed by thread T1 here: > #0 0x7fb46d651417 in __interceptor_free > ../../.././libsanitizer/asan/asan_malloc_linux.cc:62 > #1 0x7fb46cc99075 in MVM_free src/core/alloc.h:29 > #2 0x7fb46cca388b in MVM_string_flatten src/strings/ops.c:1241 > #3 0x7fb46ca027ef in MVM_interp_run src/core/interp.c:1601 > #4 0x7fb46ca9776a in start_thread src/core/threads.c:77 > #5 0x7fb46cd6152d in uv__thread_start > 3rdparty/libuv/src/unix/thread.c:49 > #6 0x7fb46bdcfaa0 in start_thread (/lib64/libpthread.so.0+0x7aa0) > > previously allocated by thread T0 here: > #0 0x7fb46d65162f in __interceptor_malloc > ../../.././libsanitizer/asan/asan_malloc_linux.cc:72 > #1 0x7fb46cc98fef in MVM_malloc src/core/alloc.h:2 > #2 0x7fb46cc9b63c in allocate_strands src/strings/ops.c:27 > #3 0x7fb46cc9d384 in MVM_string_substring src/strings/ops.c:294 > #4 0x7fb46c9feb14 in MVM_interp_run src/core/interp.c:1467 > #5 0x7fb46ccf5bf4 in MVM_vm_run_file src/moar.c:304 > #6 0x401a4f in main src/main.c:191 > #7 0x7fb46c20bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c) > > Thread T4 created by T0 here: > #0 0x7fb46d6206ea in __interceptor_pthread_create > ../../.././libsanitizer/asan/asan_interceptors.cc:183 > #1 0x7fb46cd61632 in uv_thread_create > 3rdparty/libuv/src/unix/thread.c:66 > #2 0x7fb46ca97b1b in MVM_thread_run src/core/threads.c:129 > #3 0x7fb46ca3b0a1 in MVM_interp_run src/core/interp.c:3964 > #4 0x7fb46ccf5bf4 in MVM_vm_run_file src/moar.c:304 > #5 0x401a4f in main src/main.c:191 > #6 0x7fb46c20bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c) > > Thread T1 created by T0 here: > #0 0x7fb46d6206ea in __interceptor_pthread_create > ../../.././libsanitizer/asan/asan_interceptors.cc:183 > #1 0x7fb46cd61632 in uv_thread_create > 3rdparty/libuv/src/unix/thread.c:66 > #2 0x7fb46ca97b1b in MVM_thread_run src/core/threads.c:129 > #3 0x7fb46ca3b0a1 in MVM_interp_run src/core/interp.c:3964 > #4 0x7fb46ccf5bf4 in MVM_vm_run_file src/moar.c:304 > #5 0x401a4f in main src/main.c:191 > #6 0x7fb46c20bd1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c) > > SUMMARY: AddressSanitizer: double-free > ../../.././libsanitizer/asan/asan_malloc_linux.cc:62 > __interceptor_free > ==9674==ABORTING > The need for string flattening is now gone, meaning the code path that caused this bug is also, happily, gone. In S17-promie/start.t I've added a test case that far more reliably provoked the bug (in fact, I've never seen it fail to provoke the bug).
About other notes on this ticket: * The "Could not invoke" issue that could also sometimes be triggered by the same code was fixed last week in MoarVM commit b4cd2a6555 (and is test covered) * The abort reported at exit is a `--full-cleanup` issue and unrelated to the original issue, so doesn't block closing this ticket. Also, since we only use --full-cleanup when running under valgrind, ordinary users will never see this. Thanks, /jnthn
