UBSAN_MODE_UNKNOWN

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! Other tests do fail with more descriptive errors.

Any suggestions?

Thanks,

Ben

Hi Ben,

Probably not impossible, but I don’t think I’m linking with both.

Here is an example:
http://www.boost.org/development/tests/develop/developer/output/BenPope%20x86_64%20Ubuntu-boost-bin-v2-libs-algorithm-test-any_of_test-test-clang-linux-3-7~ubsan~c14_libc+±debug.html

Ben

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

Ben

Hi Ben,

    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@entry=1, argv=argv@entry=0x7fffffffdee8, env=env@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

        Hi Ben,

        On Sun, May 3, 2015 at 9:52 PM, Ben Pope
        <benpope81@gmail.com
        <mailto:benpope81@gmail.com>
        <mailto:benpope81@gmail.com

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

Thanks for the stacktrace!

Looks like I've fixed the problem in LLVM r237045: due to a bug, UBSan
initialization was *not* called from .preinit_array as
it was supposed to, and if the function called from .init_array early
enough contained an error and tried to report it
(as in your case), the runtime was still in uninitialized state.

Could you please test your code with trunk Clang?

It's fixed. Thanks for the prompt attention, and apologies for my tardy response.

Ben