From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9384 invoked by alias); 10 Jan 2013 10:59:14 -0000 Received: (qmail 9376 invoked by uid 22791); 10 Jan 2013 10:59:13 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_BF,TW_DW,TW_FC,TW_XF X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 10 Jan 2013 10:59:07 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0AAx6gJ001252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jan 2013 05:59:06 -0500 Received: from zalov.redhat.com (vpn1-4-71.ams2.redhat.com [10.36.4.71]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r0AAx4eU021991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jan 2013 05:59:05 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r0AAx35C024789; Thu, 10 Jan 2013 11:59:03 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r0AAx3jg024788; Thu, 10 Jan 2013 11:59:03 +0100 Date: Thu, 10 Jan 2013 10:59:00 -0000 From: Jakub Jelinek To: Konstantin Serebryany Cc: GCC Patches , Dodji Seketeli , Dmitry Vyukov , Wei Mi Subject: Re: libsanitizer mege from upstream r171973 Message-ID: <20130110105903.GV7269@tucnak.redhat.com> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00527.txt.bz2 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