[cfe-users] UBSAN_MODE_UNKNOWN

[Alexey Samsonov]

On Mon, May 11, 2015 at 7:02 AM, Ben Pope <benpope81 at gmail.com> wrote:

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



> 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
>
>
> _______________________________________________
> cfe-users mailing list
> cfe-users at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-users
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20150511/d7f44ed0/attachment.html>