clang 3.5 sanitizer (ubsan) does not work

[mouse07410 (Mouse)]

Mac OS X 10.9.5, Xcode-6.1.1, Macports-2.3.3.

Macports-installed "clang-3.5 +analyzer +arm_runtime +assertions" doesn't build ubsan completely or correctly.

As a result, compiling/linking a program with "-fsanitize=undefined -fsanitized=address" succeeds in producing an executable:

$ clang++-mp-3.5 -v -fsanitize=undefined -fsanitize=address -o tj tj.cpp -lc++ -lc++abi
clang version 3.5.1 (tags/RELEASE_351/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
 "/opt/local/libexec/llvm-3.5/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -main-file-name tj.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -dwarf-column-info -resource-dir /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1 -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/uri/src -ferror-limit 19 -fmessage-length 84 -fsanitize=address,alignment,array-bounds,bool,enum,float-cast-overflow,float-divide-by-zero,integer-divide-by-zero,null,object-size,return,shift,signed-integer-overflow,unreachable,vla-bound,vptr -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/tj-65dfdd.o -x c++ tj.cpp
clang -cc1 version 3.5.1 based upon LLVM 3.5.1 default target x86_64-apple-darwin13.4.0
ignoring nonexistent directory "/usr/include/c++/v1"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-3.5/bin/../include/c++/v1
 /usr/local/include
 /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.5/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o tj /var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/tj-65dfdd.o -lc++ -lc++abi -lc++ /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/lib/darwin/libclang_rt.ubsan_osx.a -lc++ -lc++ /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/lib/darwin/libclang_rt.osx.a

But that executable does not run correctly, complaining about vptr:

/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>'

Compiling with "-fno-sanitize=vptr" produces an executable that runs perfectly:

$ clang++-mp-3.5 -fsanitize=undefined -fsanitize=address -fno-sanitize=vptr -o tj tj.cpp -lc++ -lc++abi
$ ./tj
This is a test
$ 

CFE-DEV people explained that the problem is with UBSan, as it seems (to them) to be built without RTTI support.

I tried to build clang-3.5 by myself from scratch (no Macports patches), and it appears fully functional, at least with respect to analyzers. But I'd much rather use standard maintainable port like yours.

Could you point me at what is done differently to UBSan in Macports version of clang-3.5, and how (or better yet - you :) I could undo it? Maybe as a port variant?

Thanks!

[mouse07410 (Mouse)]

Log of compilation and run of a test-program with vptr sanitizer enabled.

[mouse07410 (Mouse)]

Log of compilation and run of a test-program with vptr sanitizer disabled.

[mouse07410 (Mouse)]

Log of compilation and run of a test-program with vptr sanitizer enabled, done by my standalone (non-Macports) version of clang-3.5.

[larryv (Lawrence Velázquez)]

Was there a cfe-dev mailing list thread about this? Could you link it? And could you provide a test case?

[larryv (Lawrence Velázquez)]

Never mind, didn’t read closely enough. I can reproduce.

[mouse07410 (Mouse)]

I apologize - the thread I was referring to was from the address-sanitizer list, not CFE itself: ​https://code.google.com/p/address-sanitizer/issues/detail?id=367

I will post the test-code.

[mouse07410 (Mouse)]

Test file.

[mouse07410 (Mouse)]

Are there any findings regarding this problem? Anything that you could share?

[mouse07410 (Mouse)]

This is what the "Sanitizers" folks said in ​https://code.google.com/p/address-sanitizer/issues/detail?id=367:

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

Is UBSan library in clang-3.5 port build without RTTI? Is another library (libcxx perhaps) the culprit? I consistently cannot run a program compiled with sanitizers if it's compiled with the macports clang-3.5, and can run it fine when compiled with a non-macports clang-3.5. Help (or ideally - a fix) would be greatly appreciated!

[mouse07410 (Mouse)]

Update. clang-3.5 seems hopeless wrt. -fsanitize=vptr (just does not work), but clang-3.6 seems to have fixed this problem. I have successfully built a test program, and it worked as expected:

$ clang++-mp-3.6 -fsanitize=address -fsanitize=undefined -pipe -o t -I/opt/local/include t.cpp -L/opt/local/lib -lc++ -lc++abi
$ ./t
Program compiled and linked with mutex fine.
argc=1  argv[0]=./t
$

So I moved to clang-3.6, and am happy (so far :).

Thank you!

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, that works for me then. If you can identify what change in compiler-rt fixed this and it can be cherry-picked into the 3.5 branch, I'm willing to take the change. Otherwise, closing.