public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Konstantin Serebryany <konstantin.s.serebryany@gmail.com>
To: Jakub Jelinek <jakub@redhat.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 11:28:00 -0000	[thread overview]
Message-ID: <CAGQ9bdzaeqSw=1q1gDX_3PP9M_jX65Zy62_mB-cfoyJ1vaP8sg@mail.gmail.com> (raw)
In-Reply-To: <20130110105903.GV7269@tucnak.redhat.com>

On Thu, Jan 10, 2013 at 2:59 PM, Jakub Jelinek <jakub@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

  reply	other threads:[~2013-01-10 11:28 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
2013-01-10 11:28       ` Konstantin Serebryany [this message]
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='CAGQ9bdzaeqSw=1q1gDX_3PP9M_jX65Zy62_mB-cfoyJ1vaP8sg@mail.gmail.com' \
    --to=konstantin.s.serebryany@gmail.com \
    --cc=dodji@redhat.com \
    --cc=dvyukov@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).