search for: __interceptor_malloc

I get leaks from a system library: ==16272==ERROR: LeakSanitizer: detected memory leaks Direct leak of 148 byte(s) in 2 object(s) allocated from: #0 0x4a3172 in __interceptor_malloc .../build/../projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3 #1 0x7f575d8df1fe in wcsdup (/lib64/libedit.so.0+0x1c1fe) I don't think I can fix this... ;] -Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/l...

First off, thanks -- this is a pretty great library and it feels like I'm learning a lot. I'm getting some more experience with libfuzzer and finding that I have a couple of questions: - How does libfuzzer decide to write a new test file? What distinguishes this one from all the other cases for which new test inputs were not written? Must be something about the path taken through the

...ffd956a360, alignment=8, size=<optimized out>, this=0x192db80 <__asan::instance>) #9 __asan::asan_malloc (size=size at entry=4096, stack=stack at entry=0x7fffd956a360) at /home/brian/tmp/testing/llvm_src/llvm/projects/compiler-rt/lib/asan/asan_allocator.cc:718 #10 0x00000000004da852 in __interceptor_malloc (size=4096) at /home/brian/tmp/testing/llvm_src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:41 #11 0x00007f76e14dfc65 in operator new(unsigned long) () from /home/brian/tmp/testing/testing_install//lib/libc++.so.1 #12 0x00007f76e14dfd05 in operator new[](unsigned long) () from /home/bri...

...That's not the issue however. Eventually, I get ==17150== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f417cea3189 in bitvector_any1 /home/kfischer/julia-san/src/support/bitvector.c:177 [ snip ] Uninitialized value was created by a heap allocation #0 0x7f41815de543 in __interceptor_malloc /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 #1 0x7f417cc7d7f1 in alloc_big /home/kfischer/julia-san/src/gc.c:355 [snip] Now, by going through it in the debugger, I see (gdb) f 3 #3 0x00007f417cea318a in bitvector_any1 (b=0x60c000607240, b at...

...x4d4985) #1 0x7f6360f40b44 in __libc_start_main /tmp/buildd/glibc-2.19/csu/libc-start.c:287 #2 0x41a935 in _start (/home/stark/src/a.out+0x41a935) 0x60200000eff6 is located 0 bytes to the right of 6-byte region [0x60200000eff0,0x60200000eff6) allocated by thread T0 here: #0 0x4abceb in __interceptor_malloc /home/stark/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:40:3 #1 0x4d479e in main (/home/stark/src/a.out+0x4d479e) SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/stark/src/a.out+0x4d4985) in main Shadow bytes around the buggy address: 0x0c047fff9da0: fa fa fa fa fa fa...

...==17150== WARNING: MemorySanitizer: use-of-uninitialized-value >> #0 0x7f417cea3189 in bitvector_any1 >> /home/kfischer/julia-san/src/support/bitvector.c:177 >> [ snip ] >> >> Uninitialized value was created by a heap allocation >> #0 0x7f41815de543 in __interceptor_malloc >> /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 >> #1 0x7f417cc7d7f1 in alloc_big /home/kfischer/julia-san/src/gc.c:355 >> [snip] >> >> Now, by going through it in the debugger, I see >> >> (gdb) f 3 >...

...af0,0x602000055af1) freed by thread T0 here: ??? #0 0x7f7891a157b8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8) ??? #1 0x7f7878373d8c in XSetLocaleModifiers (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x5ad8c) previously allocated by thread T0 here: ??? #0 0x7f7891a15b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50) ??? #1 0x7f7878373984 in _XlcDefaultMapModifiers (/usr/lib/x86_64-linux-gnu/libX11.so.6+0x5a984) SUMMARY: AddressSanitizer: heap-use-after-free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x5a0f6) ------------------------------ The window with a ch...

...zed-value >> >> #0 0x7f417cea3189 in bitvector_any1 >> >> /home/kfischer/julia-san/src/support/bitvector.c:177 >> >> [ snip ] >> >> >> >> Uninitialized value was created by a heap allocation >> >> #0 0x7f41815de543 in __interceptor_malloc >> >> >> /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 >> >> #1 0x7f417cc7d7f1 in alloc_big >> /home/kfischer/julia-san/src/gc.c:355 >> >> [snip] >> >> >> >> Now, by going thr...

...17cea3189 in bitvector_any1 >>>> >> /home/kfischer/julia-san/src/support/bitvector.c:177 >>>> >> [ snip ] >>>> >> >>>> >> Uninitialized value was created by a heap allocation >>>> >> #0 0x7f41815de543 in __interceptor_malloc >>>> >> >>>> >> /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 >>>> >> #1 0x7f417cc7d7f1 in alloc_big >>>> >> /home/kfischer/julia-san/src/gc.c:355 >>>> >> [s...

...>> >> /home/kfischer/julia-san/src/support/bitvector.c:177 >> >>>> >> [ snip ] >> >>>> >> >> >>>> >> Uninitialized value was created by a heap allocation >> >>>> >> #0 0x7f41815de543 in __interceptor_malloc >> >>>> >> >> >>>> >> >> >>>> >> /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 >> >>>> >> #1 0x7f417cc7d7f1 in alloc_big >> >>>> >...

...san/msan_allocator.cc:125 #5 __msan::MsanReallocate (stack=stack at entry=0x7fffffffcf10, old_p=old_p at entry=0x0, new_size=new_size at entry=82, alignment=alignment at entry=8, zeroise=zeroise at entry=false) at ../projects/compiler-rt/lib/msan/msan_allocator.cc:180 #6 0x0000000000444bce in __interceptor_malloc (size=82) at ../projects/compiler-rt/lib/msan/msan_interceptors.cc:931 #7 0x00007ffff7de9161 in _dl_signal_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00007ffff7de9323 in _dl_signal_cerror () from /lib64/ld-linux-x86-64.so.2 #9 0x00007ffff7de40be in _dl_lookup_symbol_x () from /lib64/ld-linux...

...ils/unittest/googletest/src/gtest.cc:5356 #10 0x73080b in main /home/blitz/projects/llvm/projects/compiler-rt/lib/msan/tests/msan_test_main.cc:19:3 #11 0x7fd75b533222 in __libc_start_main (/usr/lib/libc.so.6+0x24222) Uninitialized value was created by a heap allocation #0 0x4709ec in __interceptor_malloc /home/blitz/projects/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:910:3 #1 0x7fd75baf8b0b in operator new(unsigned long) (/usr/local/lib/libc++.so.1+0x91b0b) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/a...

...ia-san/src/support/bitvector.c:177 >> >> >>>> >> [ snip ] >> >> >>>> >> >> >> >>>> >> Uninitialized value was created by a heap allocation >> >> >>>> >> #0 0x7f41815de543 in __interceptor_malloc >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_interceptors.cc:854 >> >> >>>> >> #1 0x7f417cc7d7f...

...gt; >>> >> >>>> >> [ snip ] > >>> >> >>>> >> > >>> >> >>>> >> Uninitialized value was created by a heap allocation > >>> >> >>>> >> #0 0x7f41815de543 in __interceptor_malloc > >>> >> >>>> >> > >>> >> >>>> >> > >>> >> >>>> >> > >>> >> >>>> >> > /home/kfischer/julia-san/deps/llvm-svn/projects/compiler-rt/lib/msan/msan_intercep...

...san/msan_allocator.cc:125 #5 __msan::MsanReallocate (stack=stack at entry=0x7fffffffcea0, old_p=old_p at entry=0x0, new_size=new_size at entry=73, alignment=alignment at entry=8, zeroise=zeroise at entry=false) at ../projects/compiler-rt/lib/msan/msan_allocator.cc:180 #6 0x000000000044475e in __interceptor_malloc (size=73) at ../projects/compiler-rt/lib/msan/msan_interceptors.cc:931 #7 0x00007ffff7de9161 in _dl_signal_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00007ffff7de9323 in _dl_signal_cerror () from /lib64/ld-linux-x86-64.so.2 #9 0x00007ffff7de40be in _dl_lookup_symbol_x () from /lib64/ld-linux...

I'm struggling to explain an ASAN report I'm now getting that I didn't get previously on the same code. In fact the report only happens with -O2 and not when I remove the -O flags which makes it hard to debug and makes me suspect it's dependent on exactly which instructions the code generation decides to access the bytes involved. Afaict the C code shouldn't be accessing the

...an_clang/../examples/c/test_capi.c:2794:5 #2 0x7fa7d78f960f in __libc_start_main (/usr/lib/libc.so.6+0x2060f) #3 0x55c0c024d838 in _start (/home/dsl11/dev/klee/z3/z3_upstream/build_msan_clang/c_example+0x1c838) Uninitialized value was created by a heap allocation #0 0x55c0c0253ea0 in __interceptor_malloc (/home/dsl11/dev/klee/z3/z3_upstream/build_msan_clang/c_example+0x22ea0) #1 0x7fa7e2a6c120 in memory::allocate(unsigned long) /home/dsl11/dev/klee/z3/z3_upstream/build_msan_clang/../src/util/memory_manager.cpp:276:16 #2 0x7fa7d906f125 in Z3_open_log /home/dsl11/dev/klee/z3/z3_upstream/build...

I've "successfully" built 3.9.0 release but when I run "ninja check-all" I got 208 Unexpected failures: Expected Passes : 33997 Expected Failures : 198 Unsupported Tests : 685 Unexpected Failures: 208 Below is the log I captured running "time ninja check-all | tee ninja-check-all.txt" https://drive.google.com/open?id=0B-KTY7zi7eZHU2hGYTRtd01QZjA

Hi, # TL;DR I've been building an application with and without the address sanitizer (with gcc 5.3 and clang 3.7.1) and I've observed that the application's behaviour changes (assertion hit/ not hit). I'm wondering if this could be a bug in address sanitizer or if the application I'm running is just buggy (e.g. doing bad things like relying on memory layout, etc.). I'm