Asan false positive: string literal ODR-rule violation with Clang -flto

[Techmeology]

Building a program with the same string literal in two translation units, and linking with -flto generates a false positive ODR-rule violation:

Address Sanitizer Output

=================================================================
==27699==ERROR: AddressSanitizer: odr-violation (0x558e1e2426e0):
  [1] size=5 '<string literal>' test-2.cpp:4:7
  [2] size=5 '<string literal>' test-1.cpp:5:7
These globals were registered at these points:
  [1]:
    #0 0x558e1e17b0b2 in __asan_register_globals (/home/nicholas/bug/2016011901/test+0x310b2)
    #1 0x558e1e22eb86 in asan.module_ctor.5 (/home/nicholas/bug/2016011901/test+0xe4b86)

  [2]:
    #0 0x558e1e17b0b2 in __asan_register_globals (/home/nicholas/bug/2016011901/test+0x310b2)
    #1 0x558e1e22eb46 in asan.module_ctor (/home/nicholas/bug/2016011901/test+0xe4b46)

==27699==HINT: if you don't care about these warnings you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global '<string literal>' at test-2.cpp:4:7
==27699==ABORTING

Clang Version

clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

odrlto.zip

[yugr]

FTR this is the reason ODR violation detection is disabled in GCC.

[ghost]

GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888

[kcc]

Thanks for the report, reproduced.
Obvious workarounds: don't use flto or set ASAN_OPTIONS=detect_odr_violation=0

@ygribov-samsung, are you sure this is the same bug as in the above comment?

[yugr]

I think so, check HJ's and Jakub's comments about -fmerge-all-constants and

=================================================================
==14370==ERROR: AddressSanitizer: odr-violation (0x000002b38aa0):
  [1] size=12 'CSWTCH.2819'
/export/gnu/import/git/sources/gcc/gcc/tree-vrp.c:4056:7
  [2] size=12 'CSWTCH.2820'
/export/gnu/import/git/sources/gcc/gcc/tree-vrp.c:4109:8

[kcc]

Is http://reviews.llvm.org/D15642 going to help?

[chefmax]

I'll check it out.

[chefmax]

I've checked the testcase (I needed to modify build.sh) with http://reviews.llvm.org/D15642 and http://reviews.llvm.org/D15644 and ODR violation error seems to disappear:

max@max:/tmp/odrlto$ cat build.sh 
#!/bin/bash

LLVM_ROOT=/home/max/build/llvm/
BINUTILS_PREFIX=/home/max/install/binutils/bin

rm -f test-1.a test-2.a test-1.o test-2.o

$LLVM_ROOT/bin/clang++ -fsanitize=address -c test-1.cpp  -mllvm -asan-use-private-alias=$1 -flto -O2
$BINUTILS_PREFIX/ar q test-1.a test-1.o --plugin $LLVM_ROOT/lib/LLVMgold.so
$LLVM_ROOT/bin/clang++ -fsanitize=address -c test-2.cpp  -mllvm -asan-use-private-alias=$1 -flto -O2
$BINUTILS_PREFIX/ar q test-2.a test-2.o --plugin $LLVM_ROOT/lib/LLVMgold.so
$LLVM_ROOT/bin/clang++ -fsanitize=address -o test test-1.a test-2.a -flto

max@max:/tmp/odrlto$ ./build.sh 1
/home/max/install/binutils/bin/ar: creating test-1.a
/home/max/install/binutils/bin/ar: creating test-2.a
max@max:/tmp/odrlto$ ./test 
=================================================================
==6313==ERROR: AddressSanitizer: odr-violation (0x0000004f0ec0):
  [1] size=5 '<string literal>' test-2.cpp:4:7
  [2] size=5 '<string literal>' test-1.cpp:5:7
These globals were registered at these points:
  [1]:
    #0 0x424336 in __asan_register_globals /home/max/src/llvm/projects/compiler-rt/lib/asan/asan_globals.cc:274:3
    #1 0x4dd9b9 in asan.module_ctor.5 (/tmp/odrlto/test+0x4dd9b9)

  [2]:
    #0 0x424336 in __asan_register_globals /home/max/src/llvm/projects/compiler-rt/lib/asan/asan_globals.cc:274:3
    #1 0x4dd979 in asan.module_ctor (/tmp/odrlto/test+0x4dd979)

==6313==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global '<string literal>' at test-2.cpp:4:7
==6313==ABORTING
max@max:/tmp/odrlto$ ASAN_OPTIONS=use_odr_indicator=1 ./test 
test
test
max@max:/tmp/odrlto$ 

The only issue here -- clang ICEd to compile test-{1, 2}.cpp with -mllvm -asan-use-private-alias=0 that I'm investigating now.

[chefmax]

Fixed on trunk if use -mllvm -asan-use-private-alias during compilation and ASAN_OPTIONS=use_odr_indicator=1 at runtime:

max@max:/tmp/odrlto$ ./build.sh 1
+ LLVM_ROOT=/home/max/build/llvm/
+ BINUTILS_PREFIX=/home/max/install/binutils/bin
+ rm -f test-1.a test-2.a test-1.o test-2.o
+ /home/max/build/llvm//bin/clang++ -fsanitize=address -c test-1.cpp -mllvm -asan-use-private-alias=1 -flto -O2
+ /home/max/install/binutils/bin/ar q test-1.a test-1.o --plugin /home/max/build/llvm//lib/LLVMgold.so
/home/max/install/binutils/bin/ar: creating test-1.a
+ /home/max/build/llvm//bin/clang++ -fsanitize=address -c test-2.cpp -mllvm -asan-use-private-alias=1 -flto -O2
+ /home/max/install/binutils/bin/ar q test-2.a test-2.o --plugin /home/max/build/llvm//lib/LLVMgold.so
/home/max/install/binutils/bin/ar: creating test-2.a
+ /home/max/build/llvm//bin/clang++ -fsanitize=address -o test test-1.a test-2.a -flto
max@max:/tmp/odrlto$ ASAN_OPTIONS=use_odr_indicator=1  ./test 
test
test
max@max:/tmp/odrlto$
max@max:/tmp/odrlto$ echo $?
0

So, perhaps we can close this?

[Techmeology]

Does it still break with ASAN_OPTIONS=use_odr_indicator=2? ASAN_OPTIONS=use_odr_indicator=1 works, even with 3.7.1. The reason is becuase ASAN_OPTIONS=use_odr_indicator=1 only detects ODR violations if the sizes of the objects are different. ASAN_OPTIONS=use_odr_indicator=2 detects ODR violations even when the sizes are the same.

[chefmax]

Does it still break with ASAN_OPTIONS=use_odr_indicator=2? ASAN_OPTIONS=use_odr_indicator=1 works, even with 3.7.1. The reason is becuase ASAN_OPTIONS=use_odr_indicator=1 only detects ODR violations if the sizes of the objects are different. ASAN_OPTIONS=use_odr_indicator=2 detects ODR violations even when the sizes are the same.

No-no, you have just mixed up detect_odr_violation=1 with use_odr_indicator=1.
use_odr_indicator=1 was added quite recently (http://reviews.llvm.org/rL260076) to clang 3.9 and it isn't available in 3.7.1.

[morehouse]

Merging with #398.