sanitizer prevents linking, tons of undefined references

[GoogleCodeExporter]

What steps will reproduce the problem?
1. write a trivial 6-line C++ program (attached).

2. Compile it, and try to link resulting object file. 
for example:
clang++-mp-3.5 -fsanitize=undefined -std=c++11 -o t t.cpp -lc++

3. Observe the failure and error messages.

What is the expected output? What do you see instead?

Expected output: successful creation of an executable file.

What I see instead - a bunch of error like:

$ /opt/local/bin/clang++-mp-3.5 -fsanitize=undefined -std=c++11 -o t t.cpp -lc++
Undefined symbols for architecture x86_64:
  "typeinfo for __cxxabiv1::__class_type_info", referenced from:
      __ubsan::checkDynamicType(void*, void*, unsigned long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for __cxxabiv1::__si_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for __cxxabiv1::__vmi_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

What version of the product are you using? On what operating system?

This happens with clang-3.3, clang-3.4 and clang-3.5. On Mac OS X 10.9.5. Xcode 
6.1 is installed.

Please provide any additional information below.

$ /opt/local/bin/clang++-mp-3.5 -std=c++11 -c t.cpp
$ /opt/local/bin/clang++-mp-3.5 -std=c++11 -o t t.o
$ /opt/local/bin/clang++-mp-3.5 -std=c++11 -fsanitize=undefined -c t.cpp
$ /opt/local/bin/clang++-mp-3.5 -std=c++11 -fsanitize=undefined -o t t.o
Undefined symbols for architecture x86_64:
  "typeinfo for __cxxabiv1::__class_type_info", referenced from:
      __ubsan::checkDynamicType(void*, void*, unsigned long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for __cxxabiv1::__si_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for __cxxabiv1::__vmi_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Original issue reported on code.google.com by mouse...@gmail.com on 6 Jan 2015 at 9:46

Attachments:

• t.cpp

[GoogleCodeExporter]

Note: -fsanitize=undefined is UndefinedBehaviorSanitizer, you should file bugs 
at LLVM/Clang bugzilla (compiler-rt component): http://llvm.org/bugs/

It looks like your version of UBSan runtime is built without RTTI, which is 
wrong. I don't know what build system was used to build UBSan you are using. Is 
it Apple Clang? Does it happen if you build fresh Clang from source?

As a workaround, you may try building your code with "-fsanitize=undefined 
-fno-sanitize=vptr"

Original comment by samso...@google.com on 7 Jan 2015 at 6:10

[GoogleCodeExporter]

This doesn't look like Apple Clang.

Original comment by kuba.brecka@gmail.com on 7 Jan 2015 at 7:41

[GoogleCodeExporter]

This is with MacPorts clang. Native Apple clang doesn't seem to support 
sanitizers at all.

This is Apple clang:
$ clang -v
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ clang++ -fsanitize=undefined -I/opt/local/include -o t t.cpp
clang: error: unsupported argument 'undefined' to option 'fsanitize='
$

This is MacPorts clang:
$ /opt/local/bin/clang-mp-3.5 -v
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ /opt/local/bin/clang++-mp-3.5 -fsanitize=undefined -I/opt/local/include -o t 
t.cpp
Undefined symbols for architecture x86_64:
  "typeinfo for __cxxabiv1::__class_type_info", referenced from:
      __ubsan::checkDynamicType(void*, void*, unsigned long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for __cxxabiv1::__si_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
  "typeinfo for __cxxabiv1::__vmi_class_type_info", referenced from:
      isDerivedFromAtOffset(__cxxabiv1::__class_type_info const*, __cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
      findBaseAtOffset(__cxxabiv1::__class_type_info const*, long) in libclang_rt.ubsan_osx.a(ubsan_type_hash.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ /opt/local/bin/clang++-mp-3.5 -fsanitize=undefined -fno-sanitize=vptr 
-I/opt/local/include -o t t.cpp
$ ./t
Program compiled and linked with mutex fine.
argc=1  argv[0]=./t

That means - your workaround works (now if somebody could explain to me what it 
does, and why it seems to make such a difference?).

No I haven't built Clang from source (yet). In the process (having problems 
there, but probably pilot errors) with friend experienced in Clang-building 
helping. Will report if anything useful surfaces.

Original comment by mouse...@gmail.com on 7 Jan 2015 at 10:52

[GoogleCodeExporter]

Apparently, UBSan runtime library in MacPorts Clang is built without RTTI, 
which is wrong. I don't know what build process / build system is used there...

"-fno-sanitize=vptr" works because it turns off one piece of UBSan - vptr 
checker. So, all functions defined in ubsan_type_hash.o are now unused, and 
this object file is omitted from link.

I will close this bug. If you encounter problems with upstream Clang, please 
file a bug in llvm.org/bugs (you can add me to cc there).

Original comment by samso...@google.com on 8 Jan 2015 at 2:16

• Changed state: Invalid

[GoogleCodeExporter]

Looks like I diagnosed it incorrectly at first. Could you check if adding 
-lc++abi fixes the problem for you? (see 
http://llvm.org/bugs/show_bug.cgi?id=21424)

Original comment by samso...@google.com on 13 Jan 2015 at 11:41

[GoogleCodeExporter]

Yes this seemed to work:

$ clang++ -fsanitize=undefined -fsanitize=address -stdlib=libstdc++ -o tj 
tj.cpp -lstdc++ -lc++abi
$ ./tj
This is a test

Original comment by mouse...@gmail.com on 15 Jan 2015 at 3:27

[GoogleCodeExporter]

Except that the resulting program does not seem to run properly when some 
header files (like <mutex>) are involved:

$ clang++-mp-3.5 -fsanitize=undefined -fsanitize=address -std=c++11 -o t t.cpp 
-lc++abi
$ ./t
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/locale:1509:13: runtime 
error: member call on address 0x7fff7b62f068 which does not point to an object 
of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/streambuf:360:12: runtime 
error: member call on address 0x7fff7b62f068 which does not point to an object 
of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/iterator:906:53: runtime 
error: member call on address 0x7fff7b62f068 which does not point to an object 
of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/streambuf:349:9: runtime 
error: member access within address 0x7fff7b62f068 which does not point to an 
object of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/streambuf:349:20: runtime 
error: member access within address 0x7fff7b62f068 which does not point to an 
object of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/streambuf:350:16: runtime 
error: member call on address 0x7fff7b62f068 which does not point to an object 
of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
Program compiled and linked with mutex fine.
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/ostream:965:21: runtime 
error: member call on address 0x7fff7b62f068 which does not point to an object 
of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
/opt/local/libexec/llvm-3.5/bin/../include/c++/v1/streambuf:273:12: runtime 
error: member call on address 0x7fff7b62f068 which does not point to an object 
of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >'
0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>'
 00 00 00 00  10 05 63 7b ff 7f 00 00  70 fc 62 7b ff 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00
              ^~~~~~~~~~~~~~~~~~~~~~~
              vptr for 'std::__1::__stdoutbuf<char>'
argc=1  argv[0]=./t
$ 

Here's the source:

$ cat t.cpp
#include <iostream>
#include <mutex>

int main(int argc, char **argv) {

    std::cout << "Program compiled and linked with mutex fine."
          << std::endl;

    std::cout << "argc=" << argc << "  argv[0]=" << argv[0] << std::endl;

}
$ clang++-mp-3.5 -v
clang version 3.5.0 (tags/RELEASE_350/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Original comment by mouse...@gmail.com on 15 Jan 2015 at 3:30

[GoogleCodeExporter]

Update. When I downloaded and built libcxx and libcxxabi to my manually-built 
clang (and linked with ''-lc++abi''), the above test passed OK. I.e. it 
compiled, linked, and ran correctly. That encouraged me. :-)

I observed that Macports clang++ somehow is built without RTTI (i.e. I must 
disable vptr sanitizer in order to get my stuff working).

Could you please point me at where/what in the UBSan build process controls 
whether RTTI is built or not? So that I can try to re-build the Macports clang 
with RTTI part of UBSan enabled? (I'd rather use the "standard" - aka 
Macports-built - clang than my own, if possible.)

Thanks!

Original comment by mouse...@gmail.com on 20 Jan 2015 at 9:58

[GoogleCodeExporter]

FYI there were recent improvements in ASan+UBSan compatibility, and now using 
upstream Clang with -fsanitize=address,undefined should work fine. The driver 
should now also provide -lc++abi automatically.

I'm not sure I understand your last question :/ What is the problem you observe?

Original comment by samso...@google.com on 21 Apr 2015 at 7:55

[GoogleCodeExporter]

Adding Project:AddressSanitizer as part of GitHub migration.

Original comment by ramosian.glider@gmail.com on 30 Jul 2015 at 9:14

• Added labels: ProjectAddressSanitizer