search

steleman / address-sanitizer

Automatically exported from code.google.com/p/address-sanitizer
0 stars 0 forks source link

Incomplete ASAN trace for heap use-after-free on a temporary #333

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Take ptr to temporary.
2. Access it after the full expression.

I have attached a minimal test case.

Here is the output I am getting:

==29548==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000eff8 
at pc 0x00000045cad8 bp 0x7fff68cf9f50 sp 0x7fff68cf9710
READ of size 4 at 0x60300000eff8 thread T0
    #0 0x45cad7 in __interceptor_strlen /home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:563
    #1 0x7f509226ddf8 in std::char_traits<char>::length(char const*) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/char_traits.h:259
    #2 0x7f509226ddf8 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/ostream:536
    #3 0x4b6474 in AccessFreedTemp() /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:6:3
    #4 0x4b68b4 in main /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:10:3
    #5 0x7f5091c1cde4 in __libc_start_main /build/buildd/eglibc-2.17/csu/libc-start.c:260
    #6 0x4b620a in _start (/home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test+0x4b620a)

0x60300000eff8 is located 24 bytes inside of 28-byte region 
[0x60300000efe0,0x60300000effc)
freed by thread T0 here:
    #0 0x4194b1 in operator delete(void*) /home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:94
    #1 0x7f509229305e in std::string::_Rep::_M_dispose(std::allocator<char> const&) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:538
    #2 0x7f509229305e in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:539
    #3 0x4b68b4 in main /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:10:3
    #4 0x7f5091c1cde4 in __libc_start_main /build/buildd/eglibc-2.17/csu/libc-start.c:260

previously allocated by thread T0 here:
    #0 0x418f31 in operator new(unsigned long) /home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:62
    #1 0x7f5092292f38 in __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:104
    #2 0x7f5092292f38 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:607
    #3 0x7f50924da03f (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0x30103f)

SUMMARY: AddressSanitizer: heap-use-after-free 
/home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:56
3 __interceptor_strlen

Here is (roughly) the output I would expect to see:

==29548==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000eff8 
at pc 0x00000045cad8 bp 0x7fff68cf9f50 sp 0x7fff68cf9710
READ of size 4 at 0x60300000eff8 thread T0
    #0 0x45cad7 in __interceptor_strlen /home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:563
    #1 0x7f509226ddf8 in std::char_traits<char>::length(char const*) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/char_traits.h:259
    #2 0x7f509226ddf8 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/ostream:536
    #3 0x4b6474 in AccessFreedTemp() /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:6:3
    #4 0x4b68b4 in main /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:10:3
    #5 0x7f5091c1cde4 in __libc_start_main /build/buildd/eglibc-2.17/csu/libc-start.c:260
    #6 0x4b620a in _start (/home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test+0x4b620a)

0x60300000eff8 is located 24 bytes inside of 28-byte region 
[0x60300000efe0,0x60300000effc)
freed by thread T0 here:
    #0 0x4194b1 in operator delete(void*) /home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:94
    #1 0x7f509229305e in std::string::_Rep::_M_dispose(std::allocator<char> const&) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:538
    #2 0x7f509229305e in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:539
--> line number where the temporary was freed from (this line was left out):
    #3 0x4b62f8 in AccessFreedTemp() /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:5:3
    #4 0x4b68b4 in main /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:10:3
    #5 0x7f5091c1cde4 in __libc_start_main /build/buildd/eglibc-2.17/csu/libc-start.c:260

previously allocated by thread T0 here:
    #0 0x418f31 in operator new(unsigned long) /home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:62
    #1 0x7f5092292f38 in __gnu_cxx::new_allocator<char>::allocate(unsigned long, void const*) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/ext/new_allocator.h:104
    #2 0x7f5092292f38 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) /build/buildd/gcc-4.8-4.8.1/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:607
--> actual stack trace from where the temporary was allocated (instead of a 
strange unnamed function from within libstdc++):
    #3 0x4b62f8 in AccessFreedTemp() /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:5:3
    #4 0x4b68b4 in main /home/mpercy/src/test/c++/asan_temporary_confusion/asan_temp_test.cc:10:3
    #5 0x7f5091c1cde4 in __libc_start_main /build/buildd/eglibc-2.17/csu/libc-start.c:260

SUMMARY: AddressSanitizer: heap-use-after-free 
/home/mpercy/src/llvm/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:56
3 __interceptor_strlen

Tested on Clang 3.4 final and Clang 3.6 dev (svn trunk at the time of this 
writing) on Ubuntu Linux 13.10 x86_64.

Test case attached. To run it is straightforward:

clang++ -g -fsanitize=address asan_temp_test.cc -o asan_temp_test && 
./asan_temp_test

Original issue reported on code.google.com by mpe...@gmail.com on 8 Aug 2014 at 8:52

Attachments:

GoogleCodeExporter commented 9 years ago 
Looks like a wall of text after posting, but see the stack traces I annotated 
with --> at the beginning of the line for the changes I'd expect, i.e.:

--> line number where the temporary was freed from (this line was left out):

and 

--> actual stack trace from where the temporary was allocated (instead of a 
strange unnamed function from within libstdc++):

Original comment by mpe...@gmail.com on 8 Aug 2014 at 8:55

GoogleCodeExporter commented 9 years ago 
FYI Asan uses something called "fast unwinder" to collect stack traces for 
memory allocations. Fast unwinder has to be, well, fast so relies on frame 
pointer which is not always available on most platforms so it may (and does on 
x64 and ARM) lack precision unless you recompile all your code with 
-fno-omit-frame-pointer. Another option would be running with 
ASAN_OPTIONS=fast_unwind_on_malloc=0 but that would incur bigger perf 
penalties. Setting fast_unwind_on_malloc=1 by default is a long debate but Asan 
team prefers it to be that way.

Original comment by tetra2...@gmail.com on 11 Aug 2014 at 4:35

GoogleCodeExporter commented 9 years ago 
BTW what about printing a message after reporting heap-related bug that would 
tell user to compile with -fno-omit-frame-pointer for detailed stacks?

Original comment by tetra2...@gmail.com on 11 Aug 2014 at 4:36