public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable
@ 2015-03-02 22:50 peter at lekensteyn dot nl
  2015-03-02 22:53 ` [Bug sanitizer/65285] " kcc at gcc dot gnu.org
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: peter at lekensteyn dot nl @ 2015-03-02 22:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

            Bug ID: 65285
           Summary: __asan_describe_address crashes when used with global
                    variable
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: peter at lekensteyn dot nl
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

While trying to use __asan_describe_address() on a global variable, it results
in an ASAN check failure. (Originally noticed while using it in gdb.)

cat <<SOURCE | ${CC:-cc} -fsanitize=address -g -x c - && ./a.out
int foo[10];
int main(void) {
    return __asan_describe_address(foo);
}
SOURCE

Output with GCC 4.9.2 (gcc-multilib 4.9.2-3 on Arch Linux x86_64):
==6238==AddressSanitizer CHECK failed:
/build/gcc-multilib/src/gcc-4.9-20150204/libsanitizer/sanitizer_common/sanitizer_linux.cc:558
"((MtxUnlocked)) != ((atomic_load(m, memory_order_relaxed)))" (0x0, 0x0)
    #0 0x7f00a28d8030 in __asan::AsanCheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long) (/usr/lib/libasan.so.1+0x5d030)
    #1 0x7f00a28dc293 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long) (/usr/lib/libasan.so.1+0x61293)
    #2 0x7f00a28df795 in __sanitizer::BlockingMutex::CheckLocked()
(/usr/lib/libasan.so.1+0x64795)
    #3 0x7f00a28da601 in __asan::FindThreadByStackAddress(unsigned long)
(/usr/lib/libasan.so.1+0x5f601)
    #4 0x7f00a28d60d0 in __asan::DescribeAddressIfStack(unsigned long, unsigned
long) (/usr/lib/libasan.so.1+0x5b0d0)
    #5 0x7f00a28d6552 in __asan::DescribeAddress(unsigned long, unsigned long)
(/usr/lib/libasan.so.1+0x5b552)
    #6 0x4006e8 in main /tmp/<stdin>:3
    #7 0x7f00a24f87ff in __libc_start_main (/usr/lib/libc.so.6+0x207ff)
    #8 0x400608 in _start (/tmp/a.out+0x400608)

With Clang 3.5.1 (clang 3.5.1-1 on Arch Linux x86_64) the output is:
AddressSanitizer can not describe address in more detail (wild memory access
suspected).

On gcc 4.8.2-19ubuntu1 (Ubuntu 14.04) there is no output. I have not tested
with GCC 5 yet, it takes a while to build.

Expected result: a line reporting the location of the global variable.

Output of `gcc -v` on Arch Linux x86_64:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-4.9-20150204/configure
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20150204 (prerelease) (GCC)


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
@ 2015-03-02 22:53 ` kcc at gcc dot gnu.org
  2015-03-02 22:54 ` kcc at gcc dot gnu.org
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: kcc at gcc dot gnu.org @ 2015-03-02 22:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #1 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
What happens if you properly include sanitizer/asan_interface.h?

This is what I see with fresh clang:

% cat d.cc 
#include <sanitizer/asan_interface.h>
int foo[10];
int main(void) {
  __asan_describe_address(&foo);
}
% clang -fsanitize=address  d.cc && ./a.out 
0x00000135c820 is located 0 bytes inside of global variable 'foo' defined in
'd.cc:2:5' (0x135c820) of size 40
%


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
  2015-03-02 22:53 ` [Bug sanitizer/65285] " kcc at gcc dot gnu.org
@ 2015-03-02 22:54 ` kcc at gcc dot gnu.org
  2015-03-02 23:29 ` peter at lekensteyn dot nl
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: kcc at gcc dot gnu.org @ 2015-03-02 22:54 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #2 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
and for gcc: 

% ~/gcc-inst/bin/g++ -fsanitize=address -static-libasan   d.cc && ./a.out 
0x00000134f900 is located 0 bytes inside of global variable 'foo' defined in
'd.cc:2:5' (0x134f900) of size 40
%


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
  2015-03-02 22:53 ` [Bug sanitizer/65285] " kcc at gcc dot gnu.org
  2015-03-02 22:54 ` kcc at gcc dot gnu.org
@ 2015-03-02 23:29 ` peter at lekensteyn dot nl
  2015-03-02 23:32 ` kcc at gcc dot gnu.org
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: peter at lekensteyn dot nl @ 2015-03-02 23:29 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #3 from Peter Wu <peter at lekensteyn dot nl> ---
GCC 4.9.2 cannot include the headers, it blows up on lines such as:
In file included from
/usr/lib/clang/3.5.1/include/sanitizer/common_interface_defs.h:16:0,
                 from
/usr/lib/clang/3.5.1/include/sanitizer/asan_interface.h:17,
                 from <stdin>:1:
/usr/lib/clang/3.5.1/include/stddef.h:42:42: error: missing binary operator
before token "("
 #if !defined(_PTRDIFF_T) || __has_feature(modules)
...

(gcc -I/usr/lib/clang/3.5.1/include ...)

With clang 3.5.1, it works, but *only* with "-x c++" and not "-x c".


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (2 preceding siblings ...)
  2015-03-02 23:29 ` peter at lekensteyn dot nl
@ 2015-03-02 23:32 ` kcc at gcc dot gnu.org
  2015-03-02 23:58 ` peter at lekensteyn dot nl
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: kcc at gcc dot gnu.org @ 2015-03-02 23:32 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Peter Wu from comment #3)
> GCC 4.9.2 cannot include the headers, it blows up on lines such as:
> In file included from
> /usr/lib/clang/3.5.1/include/sanitizer/common_interface_defs.h:16:0,
>                  from
> /usr/lib/clang/3.5.1/include/sanitizer/asan_interface.h:17,
>                  from <stdin>:1:
> /usr/lib/clang/3.5.1/include/stddef.h:42:42: error: missing binary operator
> before token "("
>  #if !defined(_PTRDIFF_T) || __has_feature(modules)
> ...
> 
> (gcc -I/usr/lib/clang/3.5.1/include ...)
> 
> With clang 3.5.1, it works, but *only* with "-x c++" and not "-x c".
This should work with clang trunk. 

I think I know what your problem is. 
In C, the globals by default have common linkage and asan does not instrument
them at all and thus can not properly report them. 

Use -fno-common with C. 
https://code.google.com/p/address-sanitizer/wiki/Flags


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (3 preceding siblings ...)
  2015-03-02 23:32 ` kcc at gcc dot gnu.org
@ 2015-03-02 23:58 ` peter at lekensteyn dot nl
  2015-03-03  0:02 ` kcc at gcc dot gnu.org
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: peter at lekensteyn dot nl @ 2015-03-02 23:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #5 from Peter Wu <peter at lekensteyn dot nl> ---
(In reply to Kostya Serebryany from comment #4)

> I think I know what your problem is. 
> In C, the globals by default have common linkage and asan does not
> instrument them at all and thus can not properly report them. 
> 
> Use -fno-common with C. 
> https://code.google.com/p/address-sanitizer/wiki/Flags

That seems to work, but if the flag is not set, can't something smarter be done
instead of crashing?

How does your GCC behave with the test case? The sanitizer code in GCC is
imported from Clang, I believe, so it probably does not crash either?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (4 preceding siblings ...)
  2015-03-02 23:58 ` peter at lekensteyn dot nl
@ 2015-03-03  0:02 ` kcc at gcc dot gnu.org
  2015-03-03 23:49 ` peter at lekensteyn dot nl
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: kcc at gcc dot gnu.org @ 2015-03-03  0:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #6 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
> How does your GCC behave with the test case? The sanitizer code in GCC is
> imported from Clang, I believe, so it probably does not crash either?

I get this: 
~/gcc-inst/bin/gcc -fsanitize=address -static-libasan   d.c && ./a.out 
AddressSanitizer can not describe address in more detail (wild memory access
suspected).

Did you check the GCC trunk?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (5 preceding siblings ...)
  2015-03-03  0:02 ` kcc at gcc dot gnu.org
@ 2015-03-03 23:49 ` peter at lekensteyn dot nl
  2015-03-03 23:52 ` kcc at gcc dot gnu.org
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: peter at lekensteyn dot nl @ 2015-03-03 23:49 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #7 from Peter Wu <peter at lekensteyn dot nl> ---
(In reply to Kostya Serebryany from comment #6)
> > How does your GCC behave with the test case? The sanitizer code in GCC is
> > imported from Clang, I believe, so it probably does not crash either?
> 
> I get this: 
> ~/gcc-inst/bin/gcc -fsanitize=address -static-libasan   d.c && ./a.out 
> AddressSanitizer can not describe address in more detail (wild memory access
> suspected).

I guess this is better than crashing. Is it possible to report something
better? Can't it at least report the type and address?

> Did you check the GCC trunk?

It took a while to get the build environment, but now I can confirm that I see
the same wild memory access error (tested with r221125).


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (6 preceding siblings ...)
  2015-03-03 23:49 ` peter at lekensteyn dot nl
@ 2015-03-03 23:52 ` kcc at gcc dot gnu.org
  2015-03-04  0:58 ` peter at lekensteyn dot nl
  2015-03-04  1:00 ` kcc at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: kcc at gcc dot gnu.org @ 2015-03-03 23:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Peter Wu from comment #7)
> (In reply to Kostya Serebryany from comment #6)
> > > How does your GCC behave with the test case? The sanitizer code in GCC is
> > > imported from Clang, I believe, so it probably does not crash either?
> > 
> > I get this: 
> > ~/gcc-inst/bin/gcc -fsanitize=address -static-libasan   d.c && ./a.out 
> > AddressSanitizer can not describe address in more detail (wild memory access
> > suspected).
> 
> I guess this is better than crashing. Is it possible to report something
> better? Can't it at least report the type and address?

Since asan does not instrument this global it knows nothing about it. 
Sure, it is possible to provide better diagnostic, but this is nowhere near the
top of the things we are planing to work on. Frankly, this looks like a
relatively low value feature. 

> 
> > Did you check the GCC trunk?
> 
> It took a while to get the build environment, but now I can confirm that I
> see the same wild memory access error (tested with r221125).

Let me double-check with the fresh GCC trunk. 
Does fresh Clang trunk work for you?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (7 preceding siblings ...)
  2015-03-03 23:52 ` kcc at gcc dot gnu.org
@ 2015-03-04  0:58 ` peter at lekensteyn dot nl
  2015-03-04  1:00 ` kcc at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: peter at lekensteyn dot nl @ 2015-03-04  0:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

--- Comment #9 from Peter Wu <peter at lekensteyn dot nl> ---
Tested with
clang version 3.7.0 (http://llvm.org/git/clang.git
6b7e300a9c14a2ff364d8ef8a0f7510378f38dbc) (http://llvm.org/git/llvm
258b7710d59c086656f7b26f02326d7ca69d71fd)

(http://llvm.org/git/compiler-rt.git 70b3c4464a4067db2cd9862736611fdf6739f451)

The output is still:
AddressSanitizer can not describe address in more detail (wild memory access
suspected).

I can however live with the -fno-common workaround (which sounds like a good
idea overall). I'll leave it up to you whether it will be closed as WONTFIX.

Thanks for your hints!


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug sanitizer/65285] __asan_describe_address crashes when used with global variable
  2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
                   ` (8 preceding siblings ...)
  2015-03-04  0:58 ` peter at lekensteyn dot nl
@ 2015-03-04  1:00 ` kcc at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: kcc at gcc dot gnu.org @ 2015-03-04  1:00 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65285

Kostya Serebryany <kcc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #10 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Peter Wu from comment #9)
> Tested with
> clang version 3.7.0 (http://llvm.org/git/clang.git
> 6b7e300a9c14a2ff364d8ef8a0f7510378f38dbc) (http://llvm.org/git/llvm
> 258b7710d59c086656f7b26f02326d7ca69d71fd)
> 
> (http://llvm.org/git/compiler-rt.git
> 70b3c4464a4067db2cd9862736611fdf6739f451)
> 
> The output is still:
> AddressSanitizer can not describe address in more detail (wild memory access
> suspected).
> 
> I can however live with the -fno-common workaround (which sounds like a good
> idea overall). 

Exactly, we recommend using -fno-common with asan for C to find more bugs. 


> I'll leave it up to you whether it will be closed as WONTFIX.
> 
> Thanks for your hints!


^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2015-03-04  1:00 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-02 22:50 [Bug sanitizer/65285] New: __asan_describe_address crashes when used with global variable peter at lekensteyn dot nl
2015-03-02 22:53 ` [Bug sanitizer/65285] " kcc at gcc dot gnu.org
2015-03-02 22:54 ` kcc at gcc dot gnu.org
2015-03-02 23:29 ` peter at lekensteyn dot nl
2015-03-02 23:32 ` kcc at gcc dot gnu.org
2015-03-02 23:58 ` peter at lekensteyn dot nl
2015-03-03  0:02 ` kcc at gcc dot gnu.org
2015-03-03 23:49 ` peter at lekensteyn dot nl
2015-03-03 23:52 ` kcc at gcc dot gnu.org
2015-03-04  0:58 ` peter at lekensteyn dot nl
2015-03-04  1:00 ` kcc at gcc dot gnu.org

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