search for: asan_malloc_linux

...nctions as an optimization. It only does this if the compiler is modern and GCC-like, and we are compiling in C++ mode. This, however, causes GCC to complain about signature mismatches between the glibc functions declared in malloc.h and those defined as an alias in the interceptors library: ..../asan_malloc_linux.cc:57:1: error: declaration of 'void free(void*)' has a different exception specifier /usr/include/malloc.h:66:13: error: from previous declaration 'void free(void*) throw ()' I've attached a complete hack of a patch to address this... but surely there is a better way? I'm...

...Can you go > down to the individual compile/run invocation and verify that line > numbers match (or do not match) the exact source being compiled? It seems that the stack trace is not correct on ARM: < #0 0x7966b in free /home/linaro/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30 < #1 0xffffffff (<unknown module>) Which is on x86: > #0 0x490979 in __interceptor_free /home/rengolin/devel/llvm/src/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:30 > #1 0x4b365d in main /home/rengolin/devel/llvm/src/compiler-rt/test/asan/TestCases/use...

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/llvm-dev/attachments/20150114/ceade57d/attachment.html>

...ly does this if the compiler is modern and GCC-like, and we are compiling > in C++ mode. > > This, however, causes GCC to complain about signature mismatches between the > glibc functions declared in malloc.h and those defined as an alias in the > interceptors library: > > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void free(void*)' has > a different exception specifier > /usr/include/malloc.h:66:13: error: from previous declaration 'void > free(void*) throw ()' Looking at /usr/include/malloc.h I don't see any instances of throw() (Goobuntu Lucid) S...

...> >>> > This, however, causes GCC to complain about signature mismatches >>> between the >>> > glibc functions declared in malloc.h and those defined as an alias in >>> the >>> > interceptors library: >>> > >>> > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void >>> free(void*)' has >>> > a different exception specifier >>> > /usr/include/malloc.h:66:13: error: from previous declaration 'void >>> > free(void*) throw ()' >>> Looking at /usr/include/mal...

...C-like, and we are > compiling > > in C++ mode. > > > > This, however, causes GCC to complain about signature mismatches between > the > > glibc functions declared in malloc.h and those defined as an alias in the > > interceptors library: > > > > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void free(void*)' > has > > a different exception specifier > > /usr/include/malloc.h:66:13: error: from previous declaration 'void > > free(void*) throw ()' > Looking at /usr/include/malloc.h I don't see any instances of t...

...ws.llvm.org/D46461 [asan] Set flags appropriately for RTEMS https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to be reused by Myriad RTEMS https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion when reporting Mmap failure https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to support thread restart https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack to be initialized during thread init https://reviews.llvm.org/D46468 [asan] Add target-specific files for Myriad RTEMS port...

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

...ly does this if the compiler is modern and GCC-like, and we are compiling > in C++ mode. > > This, however, causes GCC to complain about signature mismatches between > the glibc functions declared in malloc.h and those defined as an alias in > the interceptors library: > > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void free(void*)' > has a different exception specifier > /usr/include/malloc.h:66:13: error: from previous declaration 'void > free(void*) throw ()' > > > I've attached a complete hack of a patch to address this... but surely &g...

...::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/brian/tmp/testing/testing_install//lib/libc++.so.1 #13 0x000000000054bd70 in std::__1::basic_filebuf<...

...; > in C++ mode. >> > >> > This, however, causes GCC to complain about signature mismatches >> between the >> > glibc functions declared in malloc.h and those defined as an alias in >> the >> > interceptors library: >> > >> > ..../asan_malloc_linux.cc:57:1: error: declaration of 'void >> free(void*)' has >> > a different exception specifier >> > /usr/include/malloc.h:66:13: error: from previous declaration 'void >> > free(void*) throw ()' >> Looking at /usr/include/malloc.h I don't se...

Hi Evgeniy, Now that I can run check-asan without the AArch64 tests, there are a number of ARM tests that fail with the wrong line number on the CHECK line... use-after-delete.cc:20:18: error: expected string not found in input // CHECK-Linux: {{ #1 0x.* in main .*use-after-delete.cc:}}[[@LINE-10]] <stdin>:9:33: note: with expression "@LINE-10" equal to "10" #0

...Set flags appropriately for RTEMS > https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to be > reused by Myriad RTEMS > https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion when > reporting Mmap failure > https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS > https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to > support > thread restart > https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack to > be initialized during thread init > https://reviews.llvm.org/D46468 [asan] Add target-specifi...

...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 fa fa fa fa fa fa fa fa fa fa 0x0c047fff9db0: fa fa fa fa fa fa fa...

...Set flags appropriately for RTEMS > https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to be > reused by Myriad RTEMS > https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion when > reporting Mmap failure > https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS > https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to > support > thread restart > https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack to > be initialized during thread init > https://reviews.llvm.org/D46468 [asan] Add target-specifi...

...tely for RTEMS >> https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to be >> reused by Myriad RTEMS >> https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion when >> reporting Mmap failure >> https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS >> https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to support >> thread restart >> https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack to >> be initialized during thread init >> https://reviews.llvm.org/D46468 [asan] Add...

...tely for RTEMS >> https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to be >> reused by Myriad RTEMS >> https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion when >> reporting Mmap failure >> https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS >> https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to support >> thread restart >> https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack to >> be initialized during thread init >> https://reviews.llvm.org/D46468 [asan] Add...

...//reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to > be > >> reused by Myriad RTEMS > >> https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion > when > >> reporting Mmap failure > >> https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to > RTEMS > >> https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to > support > >> thread restart > >> https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack > to > >> be initialized during thread init > >> ht...

...;> https://reviews.llvm.org/D46462 [sanitizer] Allow Fuchsia symbolizer to >> be >> reused by Myriad RTEMS >> https://reviews.llvm.org/D46463 [sanitizer] On RTEMS, avoid recursion >> when >> reporting Mmap failure >> https://reviews.llvm.org/D46465 [asan] Port asan_malloc_linux.cc to RTEMS >> https://reviews.llvm.org/D46466 [asan] Add AsanThread::Restart() to >> support >> thread restart >> https://reviews.llvm.org/D46467 [asan] Add argument to allow fake stack >> to >> be initialized during thread init >> https://reviews.llvm.org...

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