On Thu, Jan 10, 2013 at 2:59 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Thu, Jan 10, 2013 at 11:07:26AM +0400, Konstantin Serebryany wrote: >> >> Our internal LLVM bots (Linux, Mac and Android) are also green, but >> >> since the changes are large something may potentially break on other >> >> platforms. >> >> >> >> Ok to commit? > > Ok, but it would be nice if the prctl stuff in asan_test.cc could be made > more robust. Not all Linux kernels support prctl (PR_SET_NAME, ...) (only > 2.6.9+), and not all prctl.h headers define PR_SET_NAME.
> So, I'd guard the prctl call with additional > #ifdef PR_SET_NAME Ok. I'd prefer to guard the whole test with #if defined(__linux__) && defined(PR_SET_NAME). > #endif > guards, and set some bool variable if the prctl failed (or if it wasn't > #called at all), and if that global bool variable was true, used a different > expected error message (.* in the place of the expected error string). > Or perhaps just have TryToSetThreadName return whether it succeeded or not, > also call TryToSetThreadName in ThreadNamesTest directly and just return > it it failed. > > BTW, I had a look at your qsort overflow testcase, and I get: > $ ./xg++ -B ./ -O2 -fsanitize=address -o overflow-in-qsort > overflow-in-qsort.cc -B ../x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ > -B ../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/ > -Wl,-rpath,../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/ > -fno-omit-frame-pointer -g > $ ASAN_OPTIONS=fast_unwind_on_fatal=1 ./overflow-in-qsort 2>&1 | > /usr/src/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py > ================================================================= > ==24758== ERROR: AddressSanitizer: global-buffer-overflow on address > 0x000000601448 at pc 0x400acf bp 0x7fffb9caee90 sp 0x7fffb9caee88 > WRITE of size 4 at 0x000000601448 thread T0 > #0 0x400ace in QsortCallback /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:19 > #1 0x3216c37bb1 in ?? ??:0 > 0x000000601448 is located 0 bytes to the right of global variable > 'global_array (overflow-in-qsort.cc)' (0x601420) of size 40 > ... > while with > $ ASAN_OPTIONS=fast_unwind_on_fatal=0 ./overflow-in-qsort 2>&1 | > /usr/src/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py > ================================================================= > ==24763== ERROR: AddressSanitizer: global-buffer-overflow on address > 0x000000601448 at pc 0x400acf bp 0x7ffff72db050 sp 0x7ffff72db048 > WRITE of size 4 at 0x000000601448 thread T0 > #0 0x400ace in QsortCallback /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:19 > #1 0x3216c37bb1 in ?? ??:0 > #2 0x3216c3809b in ?? ??:0 > #3 0x400b1b in MyQsort /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:26 > #4 0x4008c9 in main /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:33 > #5 0x3216c21734 in ?? ??:0 > #6 0x400944 in _start ??:0 > 0x000000601448 is located 0 bytes to the right of global variable > 'global_array (overflow-in-qsort.cc)' (0x601420) of size 40 > ... > which is much better (Fedora 17 x86_64). Good! > > Similarly for 32-bit: > > $ ./xg++ -B ./ -O2 -fsanitize=address -o overflow-in-qsort > overflow-in-qsort.cc -B > ../x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/ -B > ../x86_64-unknown-linux-gnu/32/libsanitizer/asan/.libs/ > -Wl,-rpath,../x86_64-unknown-linux-gnu/32/libsanitizer/asan/.libs/ > -fno-omit-frame-pointer -g -m32 > $ ASAN_OPTIONS=fast_unwind_on_fatal=1 ./overflow-in-qsort 2>&1 | > /usr/src/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py > ================================================================= > ==24774== ERROR: AddressSanitizer: global-buffer-overflow on address > 0x08049fc8 at pc 0x80488fe bp 0xffd03548 sp 0xffd0353c > WRITE of size 4 at 0x08049fc8 thread T0 > #0 0x80488fd in QsortCallback > /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:19 > #1 0x4e00fcb2 in ?? ??:0 > addr2line: '': No such file > #2 0x27ffffff in > 0x08049fc8 is located 0 bytes to the right of global variable 'global_array > (overflow-in-qsort.cc)' (0x8049fa0) of size 40 > ... > > vs. > > ASAN_OPTIONS=fast_unwind_on_fatal=0 ./overflow-in-qsort 2>&1 | > /usr/src/llvm/projects/compiler-rt/lib/asan/scripts/asan_symbolize.py > ================================================================= > ==24780== ERROR: AddressSanitizer: global-buffer-overflow on address > 0x08049fc8 at pc 0x80488fe bp 0xffbfcf88 sp 0xffbfcf7c > WRITE of size 4 at 0x08049fc8 thread T0 > #0 0x80488fd in QsortCallback > /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:19 > #1 0x4e00fcb2 in ?? ??:0 > #2 0x4e010206 in ?? ??:0 > #3 0x4e0102ee in ?? ??:0 > #4 0x8048955 in MyQsort /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:26 > #5 0x804870c in main /usr/src/gcc/obj2/gcc/overflow-in-qsort.cc:33 > #6 0x4dff8634 in ?? ??:0 > #7 0x8048794 in _start ??:0 > 0x08049fc8 is located 0 bytes to the right of global variable 'global_array > (overflow-in-qsort.cc)' (0x8049fa0) of size 40 > > Clearly asan_symbolize.py doesn't cope with debug info stripped to separate > file (I have glibc-debuginfo installed), but AFAIK > iant's libbacktrace doesn't yet either (nor understand dwz DWARF extensions, > but Fedora 17 still doesn't use them, only > Fedora 18+ does). Anyway, I've yet to see a testcase where the fast unwinder > results in better backtrace with default options > (sure, one can compile with -fno-asynchronous-unwind-tables). Yesterday I've compared the two unwinders on chromium and saw no such case (there were few where CFI-based one is better, just like with qsort). It is very likely that I will flip fast_unwind_on_fatal to 0 next week. --kcc > > Jakub
