This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- Cc: Dodji Seketeli <dseketel at redhat dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, Yury Gribov <y dot gribov at samsung dot com>, Andrew Pinski <pinskia at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, Dmitry Vyukov <dvyukov at google dot com>, Marek Polacek <polacek at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Mon, 26 May 2014 10:57:54 +0200
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <20140522094737 dot GZ10386 at tucnak dot redhat dot com> <CAGQ9bdy+j4+-immgKGdUHwc6au_jRzxCnuy=ehKZozbq6Ks2Qw at mail dot gmail dot com> <20140522110348 dot GC10386 at tucnak dot redhat dot com> <20140522114335 dot GD10386 at tucnak dot redhat dot com> <CAGQ9bdza1Stavf-3iSrqDTXBTGdHPQRqLd0xVJy82YwX6Okc-w at mail dot gmail dot com> <20140522140738 dot GF10386 at tucnak dot redhat dot com> <CAGQ9bdxLE9R_X2V8z+Gu7dzzC+yrgg5pfYNUk+C2BY9JKKVu=Q at mail dot gmail dot com> <CAGQ9bdwQXfGXhr1C4U5p9_Ou5SDYM8TYfrMNHttharGuT8OOCQ at mail dot gmail dot com> <20140523164500 dot GX10386 at tucnak dot redhat dot com> <CAGQ9bdzgBL3N06H1vvVfnuL3GusFjCh+eCiBvpH13gYrsoiG4g at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, May 26, 2014 at 11:29:28AM +0400, Konstantin Serebryany wrote:
> > Note, I think some work is needed on the library side,
> > ERROR: AddressSanitizer: unknown-crash on address 0xffc439cf at pc 0x804898e bp 0xffc438d8 sp 0xffc438cc
>
>
> With clang I get this nice report:
>
> ==20989==ERROR: AddressSanitizer: stack-buffer-overflow on address
> 0x7fffffffdf02 at pc 0x4b20db bp 0x7fffffffdd70 sp 0x7fffffffdd68
> READ of size 4 at 0x7fffffffdf02 thread T0
> #0 0x4b20da in foo(S*) /home/kcc/tmp/jakub-unaligned.c:6
> #1 0x4b2744 in main /home/kcc/tmp/jakub-unaligned.c:30
> #2 0x7ffff6bfd76c in __libc_start_main
> /build/buildd/eglibc-2.15/csu/libc-start.c:226
> #3 0x4b1e6c in _start (/usr/local/google/kcc/llvm_cmake/a.out+0x4b1e6c)
>
> Address 0x7fffffffdf02 is located in stack of thread T0 at offset 66 in frame
> #0 0x4b24ef in main /home/kcc/tmp/jakub-unaligned.c:23
So you are passing two different base-addr values to the
__asan_report_load_n ? If yes, that doesn't sound like a good idea to me,
because it will almost always generate larger code, plus the diagnostic
is incorrect, there is no 4 byte read at address 0x7fffffffdf02,
there is a 4 byte read at address 0x7fffffffdeff, where 1 byte read at
at 0x7fffffffdeff has been checked and found valid, and one byte read
at 0x7fffffffdf02 has been checked and found invalid.
So in that case IMNSHO you need to fix both asan library and llvm.
Jakub