On Mon, 05 Dec 2016 02:25:00 -0800, jan-olof.hen...@bredband.net wrote: > While running the spectests through ASAN nwc10++ found an invalid read error > in t/spec/S32-io/IO-Socket-Async.t. Have included both ASAN and valgrind > output. Note that the valgrind output is from a 32 bit system while (I > guess) nwc10's output is from a 64 bit system. > > # ASAN output > $ ./perl6-m -Ilib t/spec/S32-io/IO-Socket-Async.t > 1..13 > ok 1 - Async listen on bogus hostname > ok 2 - Async connect to unavailable server breaks promise > ok 3 - Async connect to available server keeps promise > ok 4 - Echo serverok 5 - Coped with grapheme split across packets > ok 6 - Coped with UTF-8 bytes split across packets > ok 7 - Bad UTF-8 causes quit on Supply (but program survives) > ok 8 - Discard server > ok 9 - bytes-supply > ok 10 - Server socket configured with latin-1 handles it > ok 11 - Can set encoding on incoming Supply separately > ok 12 - Latin-1 client socket correctly encodes > ================================================================= > ==9389==ERROR: AddressSanitizer: heap-use-after-free on address > 0x61100022d720 at pc 0x7f9167a547a1 bp 0x7f915d6857d0 sp 0x7f915d6857c8 > WRITE of size 8 at 0x61100022d720 thread T3 > #0 0x7f9167a547a0 in uv_timer_init 3rdparty/libuv/src/unix/timer.c:55 > #1 0x7f916781c65e in setup src/io/timers.c:24 > #2 0x7f9167804daf in setup_work src/io/eventloop.c:20 > #3 0x7f9167804fff in async_handler src/io/eventloop.c:41 > #4 0x7f9167a222f6 in uv__async_event 3rdparty/libuv/src/unix/async.c:98 > #5 0x7f9167a22699 in uv__async_io 3rdparty/libuv/src/unix/async.c:138 > #6 0x7f9167a149b1 in uv__io_poll > 3rdparty/libuv/src/unix/linux-core.c:345 > #7 0x7f9167a2433a in uv_run 3rdparty/libuv/src/unix/core.c:351 > #8 0x7f9167805169 in enter_loop src/io/eventloop.c:60 > #1 0x7f916781f0c1 in MVM_malloc src/core/alloc.h:2 > #2 0x7f9167825731 in listen_setup src/io/asyncsocket.c:719 > #3 0x7f9167804daf in setup_work src/io/eventloop.c:20 > #4 0x7f9167804fff in async_handler src/io/eventloop.c:41 > #5 0x7f9167a222f6 in uv__async_event 3rdparty/libuv/src/unix/async.c:98 > #6 0x7f9167a22699 in uv__async_io 3rdparty/libuv/src/unix/async.c:138 > #7 0x7f9167a149b1 in uv__io_poll > 3rdparty/libuv/src/unix/linux-core.c:345 > #8 0x7f9167a2433a in uv_run 3rdparty/libuv/src/unix/core.c:351 > #9 0x7f9167805169 in enter_loop src/io/eventloop.c:60 > #10 0x7f9167855b86 in invoke_handler src/6model/reprs/MVMCFunction.c:9 > #11 0x7f91677a1792 in thread_initial_invoke src/core/threads.c:56 > #12 0x7f91676f08e9 in MVM_interp_run src/core/interp.c:61 > #13 0x7f91677a1962 in start_thread src/core/threads.c:77 > #14 0x7f9167a50cc9 in uv__thread_start > 3rdparty/libuv/src/unix/thread.c:49 > #15 0x7f9166ae2aa0 in start_thread (/lib64/libpthread.so.0+0x7aa0) > > Thread T3 created by T0 here: > #0 0x7f916830d6ea in __interceptor_pthread_create > ../../.././libsanitizer/asan/asan_interceptors.cc:183 > #1 0x7f9167a50dce in uv_thread_create > 3rdparty/libuv/src/unix/thread.c:66 > #2 0x7f91677a1d13 in MVM_thread_run src/core/threads.c:129 > #3 0x7f916780559f in get_or_vivify_loop src/io/eventloop.c:97 > #4 0x7f916780571e in MVM_io_eventloop_queue_work src/io/eventloop.c:116 > #5 0x7f9167824d02 in MVM_io_socket_connect_async > src/io/asyncsocket.c:650 > #6 0x7f9167751c7c in MVM_interp_run src/core/interp.c:4150 > #7 0x7f91679e5390 in MVM_vm_run_file src/moar.c:309 > #8 0x401a4f in main src/main.c:192 > #9 0x7f9166f1ed1c in __libc_start_main (/lib64/libc.so.6+0x1ed1c) > > SUMMARY: AddressSanitizer: heap-use-after-free > 3rdparty/libuv/src/unix/timer.c:55 uv_timer_init > Shadow bytes around the buggy address: > 0x0c228003da90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c228003daa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c228003dab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c228003dac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c228003dad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > =>0x0c228003dae0: fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd > 0x0c228003daf0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa > 0x0c228003db00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 > 0x0c228003db10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c228003db20: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa > 0x0c228003db30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Heap right redzone: fb > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack partial redzone: f4 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Contiguous container OOB:fc > ASan internal: fe > ==9389==ABORTING > Fixed in MoarVM; also the UDP sockets were vulnerable to a similar problem, but we didn't have a test that hit it. I've added such a test now, which showed the related bug did indeed exist there, and also patched it. So, should be in better shape now.
/jnthn
