[MacPorts] #46638: clang 3.5 sanitizer (ubsan) does not work

[MacPorts]

#46638: clang 3.5 sanitizer (ubsan) does not work
--------------------+--------------------------------
 Reporter:  uri@…   |      Owner:  macports-tickets@…
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:  2.3.3
 Keywords:          |       Port:  clang-3.5
--------------------+--------------------------------
 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!

-- 
Ticket URL: <https://trac.macports.org/ticket/46638>
MacPorts <https://www.macports.org/>
Ports system for OS X