public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Dodji Seketeli <dodji@redhat.com>,
	       Dmitry Vyukov <dvyukov@google.com>,
	Wei Mi <wmi@google.com>
Subject: Re: libsanitizer mege from upstream r171973
Date: Thu, 10 Jan 2013 10:59:00 -0000	[thread overview]
Message-ID: <20130110105903.GV7269@tucnak.redhat.com> (raw)
In-Reply-To: <CAGQ9bdx9LW-GaLJz_1PEdsZ9v9LCeBpwv6R775dN1ha_raKMpQ@mail.gmail.com>

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
#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).

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).

	Jakub

  reply	other threads:[~2013-01-10 10:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10  7:01 Konstantin Serebryany
     [not found] ` <CAGQ9bdzbtJ3Fh1QzgqzOvMaxzm98ZnyjORk+wU46Kbi0KWwCyA@mail.gmail.com>
2013-01-10  7:08   ` Konstantin Serebryany
2013-01-10 10:59     ` Jakub Jelinek [this message]
2013-01-10 11:28       ` Konstantin Serebryany
2013-01-10 11:31         ` Jakub Jelinek
2013-01-10 11:58           ` Konstantin Serebryany
2013-01-10 12:23             ` Jakub Jelinek
2013-01-10 12:28               ` Konstantin Serebryany
2013-01-10  7:09 ` Dmitry Vyukov
2013-01-10 15:38 ` Jack Howarth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130110105903.GV7269@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=dodji@redhat.com \
    --cc=dvyukov@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=konstantin.s.serebryany@gmail.com \
    --cc=wmi@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).