[cfe-users] UBSAN_MODE_UNKNOWN

[Ben Pope]

On Wednesday, May 06, 2015 01:50 AM, Alexey Samsonov wrote:
>
> On Mon, May 4, 2015 at 5:27 PM, Ben Pope
> <benpope81 at gmail.com
> <mailto:benpope81 at gmail.com>> wrote:
>
>     On Tuesday, May 05, 2015 12:08 AM, Alexey Samsonov wrote:
>
>         Hi Ben,
>
>         On Sun, May 3, 2015 at 9:52 PM, Ben Pope
>         <benpope81 at gmail.com
>         <mailto:benpope81 at gmail.com>
>         <mailto:benpope81 at gmail.com
>         <mailto:benpope81 at gmail.com>>> wrote:
>
>              When I run with UBSAN over the Boost libraries, I get a lot of
>              output of the form:
>              ==20717==Sanitizer CHECK failed:
>
>         /home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/ubsan/ubsan_init.cc:60
>              ((UBSAN_MODE_UNKNOWN)) != ((ubsan_mode)) (0, 0)
>
>              I'm not sure what's going wrong, I was expecting something more
>              descriptive!
>
>
>         Right, I should probably add more descriptive error message...
>
>         Can you provide the details of how you compile
>         your source files and link them into libraries and executable?
>         It looks
>         like your executable is linked with both UBSan
>         runtime and ASan runtime. It can happen if the link flags used were
>         inconsistent, or you mix libraries/executables
>         built with different versions of Clang.
>
>
>     It's not impossible, but I don't think I'm linking both runtimes.
>
>
>     Here's an example:
>     http://www.boost.org/development/tests/develop/developer/output/BenPope%20x86_64%20Ubuntu-boost-bin-v2-libs-algorithm-test-all_of_test-test-clang-linux-3-7~ubsan~c14_libc++-debug.html
>
>
>
> Indeed, looks like the compile/link commands are reasonable, and the
> problem is somewhere else. On Linux, we assume that UBSan runtime will
> be initialized by calling __ubsan::InitAsStandalone() from
> .preinit_array section (i.e. very early), and that subsequent calls to
> __ubsan::InitAsStandaloneIfNecessary() will
> effectively be a no-op. Apparently, this assumption doesn't hold in your
> case.
>
> Can you send me a stack trace of this CHECK-failure? (i.e. run the
> executable under gdb and fetch stack trace from it).

Apologies for the delay.

Breakpoint 2, __ubsan::InitAsStandaloneIfNecessary() () at 
/home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/ubsan/ubsan_init.cc:60
60	    CHECK_NE(UBSAN_MODE_UNKNOWN, ubsan_mode);
(gdb) bt
#0  __ubsan::InitAsStandaloneIfNecessary() () at 
/home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/ubsan/ubsan_init.cc:60
#1  0x0000555555598da2 in ScopedReport () at 
/home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc:336
#2  0x0000555555599480 in handleTypeMismatchImpl () at 
/home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:54
#3  0x0000555555599362 in __ubsan_handle_type_mismatch () at 
/home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:75
#4  0x00007ffff77e25d0 in __self (this=<optimized out>) at 
/home/ben/development/llvm/trunk/install/release/bin/../include/c++/v1/list:218
#5  __list_node_base (this=<optimized out>) at 
/home/ben/development/llvm/trunk/install/release/bin/../include/c++/v1/list:213
#6  __list_imp (this=<optimized out>) at 
/home/ben/development/llvm/trunk/install/release/bin/../include/c++/v1/list:546
#7  list (this=0x7ffff7dd7fb8 
<boost::unit_test::runtime_config::(anonymous 
namespace)::s_test_to_run>) at 
/home/ben/development/llvm/trunk/install/release/bin/../include/c++/v1/list:819
#8  __cxx_global_var_init83 () at 
../boost/test/impl/unit_test_parameters.ipp:224
#9  0x00007ffff7de95ba in call_init (l=<optimized out>, 
argc=argc at entry=1, argv=argv at entry=0x7fffffffdee8, 
env=env at entry=0x7fffffffdef8) at dl-init.c:72
#10 0x00007ffff7de96cb in call_init (env=<optimized out>, 
argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at 
dl-init.c:30
#11 _dl_init (main_map=0x7ffff7ffe188, argc=1, argv=0x7fffffffdee8, 
env=0x7fffffffdef8) at dl-init.c:120
#12 0x00007ffff7dd9d0a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#13 0x0000000000000001 in ?? ()
#14 0x00007fffffffe248 in ?? ()
#15 0x0000000000000000 in ?? ()

Ben