Using the libc++ with ASan and UBSan from apt.llvm.org (issue in __ubsan_handle_dynamic_type_cache_miss? libc++ vs. libstdc++ clash?)

[exoosh]

Hi,

we're building a DSO on Linux against libc++ with ASan and UBSan instrumentation turned on.

A simple program then loads the DSO and during static initialization the issue occurs (excerpt):

#1 0x70f927eb9995 in __dynamic_cast /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3/libsupc++/dyncast.cc:80:28
#2 0x70f9287260d5  (/usr/lib/llvm-20/lib/clang/20/lib/linux/libclang_rt.asan-x86_64.so+0x1260d5) (BuildId: 5f516f9b88bd4a4401541f629081b4f212f55ba4)
#3 0x70f928725432  (/usr/lib/llvm-20/lib/clang/20/lib/linux/libclang_rt.asan-x86_64.so+0x125432) (BuildId: 5f516f9b88bd4a4401541f629081b4f212f55ba4)
#4 0x70f928725407 in __ubsan_handle_dynamic_type_cache_miss (/usr/lib/llvm-20/lib/clang/20/lib/linux/libclang_rt.asan-x86_64.so+0x125407) (BuildId: 5f516f9b88bd4a4401541f629081b4f212f55ba4)
#5 0x6cf91aee84cb in std::__1::basic_ifstream<char, std::__1::char_traits<char>>::basic_ifstream(char const*, unsigned int) /usr/lib/llvm-20/bin/../include/c++/v1/fstream:1156:60
...

The call at position 5 is essentially this line: std::ifstream cmdlineFile("/proc/self/cmdline");.

It took me a while to realize, but as you can see my DSO linked against libc++ as evidenced by the presence of /usr/lib/llvm-20/bin/../include/c++/v1/fstream at position 5.

However, at position 1 we can see /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3/libsupc++/dyncast.cc which is clearly related to libstdc++!

I think the issue here is that the ASan runtime library is linked against libstdc++, which can be confirmed by:

$ readelf -a /usr/lib/llvm-20/lib/clang/20/lib/linux/libclang_rt.asan-x86_64.so|grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]

... so seemingly UBSan attempts to validate an object with dynamic_cast from libstdc++, whereas the object got created with libc++?

Is there an extra set of sanitizer runtime libraries that comes with libc++-dev (libc++-20-dev) that I can use, or do I have to build my own?

[firewave]

Does this also happen when you use LLVM 19?

[exoosh]

Does this also happen when you use LLVM 19?

Hi @firewave, yes it does (see below). But of course the libc++ used in this case is still version 20.x because there can be only on libc++ at a given time:

AddressSanitizer:DEADLYSIGNAL
=================================================================
==148883==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x7f53b71553c8 bp 0x7ffe856a2b90 sp 0x7ffe856a2b90 T0)
==148883==The signal is caused by a READ memory access.
==148883==Hint: address points to the zero page.
    #0 0x7f53b71553c8 in __cxxabiv1::__si_class_type_info::has_unambiguous_public_base(__cxxabiv1::__dynamic_cast_info*, void*, int) const (_build/Release/lib/libfoo.so+0xe7553c8) (BuildId: edab929666b202093698c344c953ba98a49feca8)
    #1 0x7f53be8b9995 in __dynamic_cast /build/gcc-14-ig5ci0/gcc-14-14.2.0/build/x86_64-linux-gnu/libstdc++-v3/libsupc++/../../../../src/libstdc++-v3/libsupc++/dyncast.cc:80:28
    #2 0x7f53bf11da33  (/usr/lib/llvm-19/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.so+0x11da33) (BuildId: 099ae46d67ba6d4420a132d1488f30c4c6978d9e)
    #3 0x7f53bf11cdc2  (/usr/lib/llvm-19/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.so+0x11cdc2) (BuildId: 099ae46d67ba6d4420a132d1488f30c4c6978d9e)
    #4 0x7f53bf11cd97 in __ubsan_handle_dynamic_type_cache_miss (/usr/lib/llvm-19/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.so+0x11cd97) (BuildId: 099ae46d67ba6d4420a132d1488f30c4c6978d9e)
    #5 0x7f53b113eafb in std::__1::basic_ifstream<char, std::__1::char_traits<char>>::basic_ifstream(char const*, unsigned int) /usr/include/c++/v1/fstream:1156:60

(I only edited the library name and path of our DSO)

Let me see if I can cobble together a MWE for you to reproduce this.

[firewave]

Thanks. A reproducer is always helpful.

But I will not be working on it. I was asking since I was wondering if this might be related to #144501.

[exoosh]

Okay, I tried but I am unable to get the libclang_rt.asan-x86_64.so to make its call to dynamic_cast (actually __dynamic_cast). Unfortunately there appears to be some precondition to when that gets called and I was unable to find the implementation for __ubsan_handle_dynamic_type_cache_miss; only saw a reference to it in a test, inside an .ll file.

My attempt so far: https://github.com/exoosh/llvm-issue-145299

This was attempted on Ubuntu 24.04 (fully up-to-date) with the packages from apt.llvm.org (both Clang 19 and 20 but libc++ 20).

[exoosh]

One thing that also worries me: One could of course attempt to use the .a, but is that really ABI agnostic? I have noticed that thanks to name mangling implementation details of each of the C++ runtime libraries tend to end up in symbol names, thereby mandating linking one or the other to get the missing symbols.

I.e. it's not like with C runtimes where the referenced symbol would conventionally be printf or fopen right until the time the linker does its thing ... and only later these symbols acquire symbol versions (e.g. with GLIBC).

And either way all documentation basically states that I must dynamically link at least the ASan runtime — which to me insinuates that using UBSan and ASan in tandem means dynamically linking both.