Closed p6rt closed 7 years ago
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.
==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
==================== This is Rakudo Perl 6 running in valgrind, a tool for debugging and profiling programs. Running a program in valgrind usually takes *a lot* more time than running it directly, so please be patient. This Rakudo version is 2016.11.130.gfa.82.a.1.f.85 built on MoarVM version 2016.11.25.g.4.be.6.b.384, running on ubuntu (14.04.3.LTS.Trusty.Tahr) / linux (3.19.0.32.generic)
==20712== Memcheck, a memory error detector ==20712== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==20712== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==20712== Command: /home/dogbert/repos/rakudo/install/bin/moar --execname=./perl6-ugga --libpath=/home/dogbert/repos/rakudo/install/share/nqp/lib --libpath=. /home/dogbert/repos/rakudo/perl6.moarvm t/spec/S32-io/IO-Socket-Async.t ==20712== 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 server ok 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 ==20712== Thread 4: ==20712== Invalid write of size 4 ==20712== at 0x41D9269: uv_timer_init (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x412140C: setup (timers.c:24) ==20712== by 0x4117A47: setup_work (eventloop.c:20) ==20712== by 0x4117B46: async_handler (eventloop.c:41) ==20712== by 0x41CDFA4: uv__async_event (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x41CE0A5: uv__async_io (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x41CA591: uv__io_poll (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x41CE992: uv_run (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x4117BEC: enter_loop (eventloop.c:60) ==20712== by 0x4133831: invoke_handler (MVMCFunction.c:9) ==20712== by 0x40F5711: thread_initial_invoke (threads.c:56) ==20712== by 0x40C1D80: MVM_interp_run (interp.c:61) ==20712== Address 0x9b0cff8 is 16 bytes inside a block of size 132 free'd ==20712== at 0x402B3D8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x41223F0: MVM_free (alloc.h:29) ==20712== by 0x41246DF: listen_setup (asyncsocket.c:739) ==20712== by 0x4117A47: setup_work (eventloop.c:20) ==20712== by 0x4117B46: async_handler (eventloop.c:41) ==20712== by 0x41CDFA4: uv__async_event (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x41CE0A5: uv__async_io (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x41CA591: uv__io_poll (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x41CE992: uv_run (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x4117BEC: enter_loop (eventloop.c:60) ==20712== by 0x4133831: invoke_handler (MVMCFunction.c:9) ==20712== by 0x40F5711: thread_initial_invoke (threads.c:56) ==20712== ok 13 - Address already in use results in a quit ==20712== ==20712== HEAP SUMMARY: ==20712== in use at exit: 145,775,433 bytes in 305,293 blocks ==20712== total heap usage: 491,602 allocs, 186,309 frees, 216,702,406 bytes allocated ==20712== ==20712== Thread 1: ==20712== 8 bytes in 1 blocks are possibly lost in loss record 277 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x40F5480: MVM_malloc (alloc.h:2) ==20712== by 0x40F582C: MVM_thread_run (threads.c:111) ==20712== by 0x4117D5C: get_or_vivify_loop (eventloop.c:97) ==20712== by 0x4117DDB: MVM_io_eventloop_queue_work (eventloop.c:116) ==20712== by 0x412422B: MVM_io_socket_connect_async (asyncsocket.c:650) ==20712== by 0x40DD60B: MVM_interp_run (interp.c:4150) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 8 bytes in 1 blocks are definitely lost in loss record 278 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4194DAE: MVM_malloc (alloc.h:2) ==20712== by 0x4195D6E: MVM_string_utf8_decodestream (utf8.c:344) ==20712== by 0x4192F03: run_decode (decode_stream.c:94) ==20712== by 0x4193A82: MVM_string_decodestream_get_available (decode_stream.c:418) ==20712== by 0x415AA68: MVM_decoder_take_available_chars (Decoder.c:201) ==20712== by 0x40E48C8: MVM_interp_run (interp.c:5068) ==20712== by 0x40F578F: start_thread (threads.c:77) ==20712== by 0x41D8286: uv__thread_start (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x45DCF71: start_thread (pthread_create.c:312) ==20712== by 0x44CCF8D: clone (clone.S:129) ==20712== ==20712== 32 bytes in 1 blocks are possibly lost in loss record 804 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A328A: generate_codepoints_by_name (unicode.c:49813) ==20712== by 0x41A5E49: MVM_unicode_lookup_by_name (unicode.c:49840) ==20712== by 0x40CB67C: MVM_interp_run (interp.c:1520) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 32 bytes in 1 blocks are possibly lost in loss record 805 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A3D67: generate_codepoints_by_name (unicode.c:49818) ==20712== by 0x41A5E49: MVM_unicode_lookup_by_name (unicode.c:49840) ==20712== by 0x40CB67C: MVM_interp_run (interp.c:1520) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 32 bytes in 1 blocks are possibly lost in loss record 806 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A4844: generate_codepoints_by_name (unicode.c:49823) ==20712== by 0x41A5E49: MVM_unicode_lookup_by_name (unicode.c:49840) ==20712== by 0x40CB67C: MVM_interp_run (interp.c:1520) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 32 bytes in 1 blocks are possibly lost in loss record 807 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A5321: generate_codepoints_by_name (unicode.c:49828) ==20712== by 0x41A5E49: MVM_unicode_lookup_by_name (unicode.c:49840) ==20712== by 0x40CB67C: MVM_interp_run (interp.c:1520) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 36 bytes in 9 blocks are definitely lost in loss record 898 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4155D36: MVM_malloc (alloc.h:2) ==20712== by 0x4155FDB: deserialize_repr_data (NativeRef.c:45) ==20712== by 0x416A47A: deserialize_stable (serialization.c:2617) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x4161F4C: MVM_sc_get_sc_object (sc.c:198) ==20712== by 0x40D58C0: MVM_interp_run (interp.c:3010) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 84 bytes in 3 blocks are possibly lost in loss record 1,256 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x40F8A46: MVM_calloc (alloc.h:11) ==20712== by 0x40F9001: MVM_load_bytecode (loadbytecode.c:71) ==20712== by 0x40D5DCD: MVM_interp_run (interp.c:3071) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 112 bytes in 2 blocks are definitely lost in loss record 1,394 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163011: MVM_malloc (alloc.h:2) ==20712== by 0x4169DE0: deserialize_stable (serialization.c:2515) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x4161F4C: MVM_sc_get_sc_object (sc.c:198) ==20712== by 0x40D58C0: MVM_interp_run (interp.c:3010) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 112 bytes in 14 blocks are definitely lost in loss record 1,395 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163011: MVM_malloc (alloc.h:2) ==20712== by 0x4169F2F: deserialize_stable (serialization.c:2534) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x40EE9FB: MVM_frame_vivify_lexical (frame.c:1128) ==20712== by 0x41424F7: at_key (MVMContext.c:60) ==20712== by 0x40D146C: MVM_interp_run (interp.c:2294) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 136 bytes in 1 blocks are definitely lost in loss record 1,455 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x401113E: allocate_dtv (dl-tls.c:296) ==20712== by 0x40118AB: _dl_allocate_tls (dl-tls.c:460) ==20712== by 0x45DD79C: allocate_stack (allocatestack.c:589) ==20712== by 0x45DD79C: pthread_create@@GLIBC_2.1 (pthread_create.c:500) ==20712== by 0x41D82E0: uv_thread_create (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x40F58E5: MVM_thread_run (threads.c:129) ==20712== by 0x4117D5C: get_or_vivify_loop (eventloop.c:97) ==20712== by 0x4117DDB: MVM_io_eventloop_queue_work (eventloop.c:116) ==20712== by 0x412422B: MVM_io_socket_connect_async (asyncsocket.c:650) ==20712== by 0x40DD60B: MVM_interp_run (interp.c:4150) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 224 bytes in 7 blocks are possibly lost in loss record 1,616 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A860F: generate_unicode_property_values_hashes (unicode.c:50011) ==20712== by 0x41AAB15: MVM_unicode_init (unicode.c:50089) ==20712== by 0x41BBDD7: MVM_vm_create_instance (moar.c:165) ==20712== by 0x8048DE0: main (main.c:182) ==20712== ==20712== 256 bytes in 8 blocks are possibly lost in loss record 1,651 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A92F8: generate_unicode_property_values_hashes (unicode.c:50017) ==20712== by 0x41AAB15: MVM_unicode_init (unicode.c:50089) ==20712== by 0x41BBDD7: MVM_vm_create_instance (moar.c:165) ==20712== by 0x8048DE0: main (main.c:182) ==20712== ==20712== 256 bytes in 8 blocks are possibly lost in loss record 1,652 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4113C8C: MVM_calloc (alloc.h:11) ==20712== by 0x411419E: MVM_gc_object_id (objectid.c:26) ==20712== by 0x40DECEB: MVM_interp_run (interp.c:4342) ==20712== by 0x40F578F: start_thread (threads.c:77) ==20712== by 0x41D8286: uv__thread_start (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x45DCF71: start_thread (pthread_create.c:312) ==20712== by 0x44CCF8D: clone (clone.S:129) ==20712== ==20712== 256 bytes in 32 blocks are definitely lost in loss record 1,653 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163011: MVM_malloc (alloc.h:2) ==20712== by 0x4169F2F: deserialize_stable (serialization.c:2534) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x4161F4C: MVM_sc_get_sc_object (sc.c:198) ==20712== by 0x40D58C0: MVM_interp_run (interp.c:3010) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 350 bytes in 41 blocks are definitely lost in loss record 1,720 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163011: MVM_malloc (alloc.h:2) ==20712== by 0x4167A69: MVM_serialization_read_cstr (serialization.c:1646) ==20712== by 0x416A436: deserialize_stable (serialization.c:2610) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x4161F4C: MVM_sc_get_sc_object (sc.c:198) ==20712== by 0x40D58C0: MVM_interp_run (interp.c:3010) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 432 bytes in 9 blocks are definitely lost in loss record 1,802 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163052: MVM_calloc (alloc.h:11) ==20712== by 0x416A052: deserialize_stable (serialization.c:2552) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x4161F4C: MVM_sc_get_sc_object (sc.c:198) ==20712== by 0x40D58C0: MVM_interp_run (interp.c:3010) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 436 bytes in 14 blocks are definitely lost in loss record 1,804 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163011: MVM_malloc (alloc.h:2) ==20712== by 0x4167A69: MVM_serialization_read_cstr (serialization.c:1646) ==20712== by 0x416A436: deserialize_stable (serialization.c:2610) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x40EE9FB: MVM_frame_vivify_lexical (frame.c:1128) ==20712== by 0x41424F7: at_key (MVMContext.c:60) ==20712== by 0x40D146C: MVM_interp_run (interp.c:2294) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 504 bytes in 18 blocks are possibly lost in loss record 1,845 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x40F8A46: MVM_calloc (alloc.h:11) ==20712== by 0x40F9001: MVM_load_bytecode (loadbytecode.c:71) ==20712== by 0x40D5DCD: MVM_interp_run (interp.c:3071) ==20712== by 0x41BC52D: MVM_vm_run_file (moar.c:296) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 680 bytes in 5 blocks are definitely lost in loss record 1,907 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x401113E: allocate_dtv (dl-tls.c:296) ==20712== by 0x40118AB: _dl_allocate_tls (dl-tls.c:460) ==20712== by 0x45DD79C: allocate_stack (allocatestack.c:589) ==20712== by 0x45DD79C: pthread_create@@GLIBC_2.1 (pthread_create.c:500) ==20712== by 0x41D82E0: uv_thread_create (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x40F58E5: MVM_thread_run (threads.c:129) ==20712== by 0x40DC3B1: MVM_interp_run (interp.c:3961) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 776 bytes in 14 blocks are definitely lost in loss record 1,941 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x4163011: MVM_malloc (alloc.h:2) ==20712== by 0x4169DE0: deserialize_stable (serialization.c:2515) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x40EE9FB: MVM_frame_vivify_lexical (frame.c:1128) ==20712== by 0x41424F7: at_key (MVMContext.c:60) ==20712== by 0x40D146C: MVM_interp_run (interp.c:2294) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 1,216 bytes in 38 blocks are possibly lost in loss record 2,046 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A262C: generate_codepoints_by_name (unicode.c:49802) ==20712== by 0x41A5E49: MVM_unicode_lookup_by_name (unicode.c:49840) ==20712== by 0x40CB67C: MVM_interp_run (interp.c:1520) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 1,496 bytes in 11 blocks are definitely lost in loss record 2,068 of 2,673 ==20712== at 0x402C109: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x401113E: allocate_dtv (dl-tls.c:296) ==20712== by 0x40118AB: _dl_allocate_tls (dl-tls.c:460) ==20712== by 0x45DD79C: allocate_stack (allocatestack.c:589) ==20712== by 0x45DD79C: pthread_create@@GLIBC_2.1 (pthread_create.c:500) ==20712== by 0x41D82E0: uv_thread_create (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x40F58E5: MVM_thread_run (threads.c:129) ==20712== by 0x40DC3B1: MVM_interp_run (interp.c:3961) ==20712== by 0x40F578F: start_thread (threads.c:77) ==20712== by 0x41D8286: uv__thread_start (in /home/dogbert/repos/rakudo/install/lib/libmoar.so) ==20712== by 0x45DCF71: start_thread (pthread_create.c:312) ==20712== by 0x44CCF8D: clone (clone.S:129) ==20712== ==20712== 6,900 (896 direct, 6,004 indirect) bytes in 14 blocks are definitely lost in loss record 2,328 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x413470E: MVM_malloc (alloc.h:2) ==20712== by 0x4137CB2: deserialize_repr_data (P6opaque.c:972) ==20712== by 0x416A47A: deserialize_stable (serialization.c:2617) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x40EE9FB: MVM_frame_vivify_lexical (frame.c:1128) ==20712== by 0x41424F7: at_key (MVMContext.c:60) ==20712== by 0x40D146C: MVM_interp_run (interp.c:2294) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 10,084 (2,048 direct, 8,036 indirect) bytes in 32 blocks are definitely lost in loss record 2,395 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x413470E: MVM_malloc (alloc.h:2) ==20712== by 0x4137CB2: deserialize_repr_data (P6opaque.c:972) ==20712== by 0x416A47A: deserialize_stable (serialization.c:2617) ==20712== by 0x416A721: work_loop (serialization.c:2684) ==20712== by 0x416A8E0: MVM_serialization_demand_object (serialization.c:2721) ==20712== by 0x4161E59: MVM_sc_get_object (sc.c:182) ==20712== by 0x4161F4C: MVM_sc_get_sc_object (sc.c:198) ==20712== by 0x40D58C0: MVM_interp_run (interp.c:3010) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 103,424 bytes in 3,232 blocks are possibly lost in loss record 2,588 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A7694: generate_unicode_property_values_hashes (unicode.c:49996) ==20712== by 0x41AAB15: MVM_unicode_init (unicode.c:50089) ==20712== by 0x41BBDD7: MVM_vm_create_instance (moar.c:165) ==20712== by 0x8048DE0: main (main.c:182) ==20712== ==20712== 120,032 bytes in 3,751 blocks are possibly lost in loss record 2,594 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A67C7: generate_property_codes_by_names_aliases (unicode.c:49970) ==20712== by 0x41A71A4: MVM_unicode_name_to_property_code (unicode.c:49983) ==20712== by 0x40CB8EC: MVM_interp_run (interp.c:1545) ==20712== by 0x41BC52D: MVM_vm_run_file (moar.c:296) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== 1,020,704 bytes in 31,897 blocks are possibly lost in loss record 2,652 of 2,673 ==20712== at 0x402A17C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==20712== by 0x419F606: MVM_malloc (alloc.h:2) ==20712== by 0x41A193C: generate_codepoints_by_name (unicode.c:49786) ==20712== by 0x41A5E49: MVM_unicode_lookup_by_name (unicode.c:49840) ==20712== by 0x40CB67C: MVM_interp_run (interp.c:1520) ==20712== by 0x41BC557: MVM_vm_run_file (moar.c:309) ==20712== by 0x8048EA5: main (main.c:192) ==20712== ==20712== LEAK SUMMARY: ==20712== definitely lost: 7,774 bytes in 199 blocks ==20712== indirectly lost: 14,040 bytes in 668 blocks ==20712== possibly lost: 1,246,836 bytes in 38,967 blocks ==20712== still reachable: 144,506,783 bytes in 265,459 blocks ==20712== suppressed: 0 bytes in 0 blocks ==20712== Reachable blocks (those to which a pointer was found) are not shown. ==20712== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==20712== ==20712== For counts of detected and suppressed errors, rerun with: -v ==20712== ERROR SUMMARY: 29 errors from 29 contexts (suppressed: 0 from 0)
On Mon, 05 Dec 2016 02:25:00 -0800, jan-olof.hendig@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
The RT System itself - Status changed from 'new' to 'open'
@jnthn - Status changed from 'open' to 'resolved'
Migrated from rt.perl.org#130266 (status was 'resolved')
Searchable as RT130266$