http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #7 from Alexander Potapenko <glider at google dot com> --- If I compile stack-overflow-1.c with 'clang -fsanitize=address -c', the resulting object file can be linked into an executable with either 'clang -fsanitize=address' or 'gcc -fsanitize=address' (this requires declaring "void *__asan_mapping_offset=0x100000000000;", since the GCC instrumentation pass doesn't insert the mapping offset). The executable linked with Clang works just fine, while the GCC one crashes on the same env_ptr assertion. Clang: $ $CLANG stack-overflow-1.o -fsanitize=address -v && ./a.out ... "/usr/bin/ld" -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o a.out stack-overflow-1.o -lstdc++ /Users/glider/src/asan/llvm/llvm_cmake_build/bin/../lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem ================================================================= ==37032==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5add8aea at pc 0x104e27c93 bp 0x7fff5add89f0 sp 0x7fff5add89e8 ... GCC: $ $GCC stack-overflow-1.o -fsanitize=address -v && ./a.out ... /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.5 -weak_reference_mismatches non-weak -o a.out -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0 -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/../../.. stack-overflow-1.o -lasan -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v ... ==37029==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:146 "((env_ptr)) != (0)" (0x0, 0x0) This seems to have nothing to do with the linkage order: I've tried to change the order of -l flags in the ld invocation from $GCC, but that didn't work. However when I replaced '-lasan' with the full path to the ASan runtime from the Clang build, it worked fine. So there's some subtle difference between the ASan runtimes compiled when building GCC and Clang.
