Invoke a fatal stack trace unwinder when ASan prints allocator-relevant
error reports (double-free, alloc-dealloc-mismatch, invalid-free).
Thus we'll be able to print complete stack trace even if allocation/free
stacks are not stored (malloc_context_size=0).
Based on the patch by Yuri Gribov!
llvm-svn: 194579
Due to bugs in the interposition of resolver functions on 10.7 and 10.8 both memcpy() and memmove()
were previously intercepted by INTERCEPTOR(memcpy), which led to false positives and crashes (see http://llvm.org/bugs/show_bug.cgi?id=16362)
We choose to use a memmove-like function in both cases. This effectively disables the overlap checks in memcpy(), but the overlaps
aren't possible in practice, because memcpy() and memmove() are the same function on Darwin.
Once the interposition is fixed in 10.9, we'll need to revisit this issue, see https://code.google.com/p/address-sanitizer/issues/detail?id=226
llvm-svn: 191081
(1) instrumented, i.e. compiled and linked with -fsanitize=address
(2) not instrumented, compiled w/o -fsanitize=address and linked with ASan runtime statically.
llvm-svn: 190788
Summary:
With this change, the user may safely call __asan_get_ownership()
from malloc/free hooks and assume it would return "true". If there is a
realloc/free race, free hook might be called twice, but I think it's acceptable,
as it's a data race and would later be reported anyway.
This change also fixes a bug when failing realloc incorrectly marked the
original memory as "quarantinned".
Reviewers: timurrrr, kcc, samsonov
Reviewed By: samsonov
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D913
llvm-svn: 183220
Before: the function name was stored by the compiler as a constant string
and the run-time was printing it.
Now: the PC is stored instead and the run-time prints the full symbolized frame.
This adds a couple of instructions into every function with non-empty stack frame,
but also reduces the binary size because we store less strings (I saw 2% size reduction).
This change bumps the asan ABI version to v3.
compiler-rt part, llvm part will follow.
Example of report (now):
==31711==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffa77cf1c5 at pc 0x41feb0 bp 0x7fffa77cefb0 sp 0x7fffa77cefa8
READ of size 1 at 0x7fffa77cf1c5 thread T0
#0 0x41feaf in Frame0(int, char*, char*, char*) stack-oob-frames.cc:20
#1 0x41f7ff in Frame1(int, char*, char*) stack-oob-frames.cc:24
#2 0x41f477 in Frame2(int, char*) stack-oob-frames.cc:28
#3 0x41f194 in Frame3(int) stack-oob-frames.cc:32
#4 0x41eee0 in main stack-oob-frames.cc:38
#5 0x7f0c5566f76c (/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#6 0x41eb1c (/usr/local/google/kcc/llvm_cmake/a.out+0x41eb1c)
Address 0x7fffa77cf1c5 is located in stack of thread T0 at offset 293 in frame
#0 0x41f87f in Frame0(int, char*, char*, char*) stack-oob-frames.cc:12 <<<<<<<<<<<<<< this is new
This frame has 6 object(s):
[32, 36) 'frame.addr'
[96, 104) 'a.addr'
[160, 168) 'b.addr'
[224, 232) 'c.addr'
[288, 292) 's'
[352, 360) 'd'
llvm-svn: 177723
Alexey Samsonov