GCC 6.2 ASAN issue with -O2 and std::atomic::load()

[Paul Smith <psmith@xxxxxxx>]

Hi all.  Back in January I reported an issue with ASAN finding "unknown-
crash" errors that I couldn't understand in GCC 5.3.  We decided to wait
and not use that version of GCC (for other reasons).  Since then I've
upgraded to GCC 6.2 and I see a similar but not identical error.

FYI: GCC 6.2 / binutils 2.27, built myself locally.  I'm on Intel 64bit
running GNU/Linux (various distros).

If I compile my code with "-g -O0", then I don't see any ASAN issues. 
However, if I compile with "-g -O2" then I get ASAN failures when I'm
using std::atomic::load(), in various other places.  The code works fine
and valgrind doesn't complain about it (for what that's worth).  Also I
can't quite figure out what ASAN is really complaining about.

It doesn't seem to fail at every single use of std::atomic::load(). 
However my system is heavily threaded so I'm wondering if some aspect of
using ASAN is not working with optimized atomic operations?

FWIW, I can build and run the code with Clang 3.8 (and Clang STL) with
ASAN and optimization enabled and it doesn't give these errors.  Maybe a
difference in the way atomics are implemented, or optimized?  Or a
difference in ASAN itself between the two compilers?


My stack trace looks like this:

==19552==ERROR: AddressSanitizer: unknown-crash on address 0x7fab2f1ecfa0 at pc 0x0000010bc01e bp 0x7fab34f95c70 sp 0x7fab34f95c68
READ of size 800008 at 0x7fab2f1ecfa0 thread T4
    #0 0x10bc01d in std::__atomic_base<Foo*>::load(std::memory_order) const /tools/cc/generic/x86_64-generic-linux-gnu/include/c++/6.2.0/bits/atomic_base.h:713
    #1 0x10bc01d in std::atomic<Foo*>::load(std::memory_order) const /tools/cc/generic/x86_64-generic-linux-gnu/include/c++/6.2.0/atomic:416
    #2 0x10bc01d in Atomic<Foo*, (std::memory_order)5, (std::memory_order)5, (std::memory_order)5>::operator Foo*() const /code/Foundation/Atomic.h:219
    #3 0x10bc01d in MyHashTable<Foo, 100001u>::insert(Foo*, bool) /code/Platform/MyHashTable.h:136
    #4 0x10bc01d in FooMgr::insert(Foo*) /code/Platform/FooMgr.cpp:3201
  ...

0x7fab2f2b0470 is located 0 bytes to the right of 834672-byte region [0x7fab2f1e4800,0x7fab2f2b0470)
allocated by thread T14 here:
    #0 0x5bab98 in malloc (/code/dist/bin/myexe+0x5bab98)
    #1 0x5d5e1d in MemMgrAllocate /code/Foundation/SysMemory.cpp:41
    #2 0x102baf9 in operator new(unsigned long) /code/Foundation/Allocator.h:101
    #3 0x102baf9 in Objects::createObject() /code/Platform/Objects.cpp:65
  ...

SUMMARY: AddressSanitizer: unknown-crash /tools/cc/generic/x86_64-generic-linux-gnu/include/c++/6.2.0/bits/atomic_base.h:713 in std::__atomic_base<Foo*>::load(std::memory_order) const
Shadow bytes around the buggy address:
  0x0ff5e5e359a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e359b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e359c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e359d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e359e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ff5e5e359f0: 00 00 00 00[00]00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e35a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e35a10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e35a20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e35a30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ff5e5e35a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  ...