Description
Apologies if this isn't the right place, it isn't obvious to me if this originates in rustc or should be upstreamed to FreeBSD.
My limited understand of the warnings however suggests it could be a misuse of thread_locals on our end.
// src/main.rs
fn main() {}$ rustc src/main.rs
__cxa_thread_call_dtors: dtr 0x2669357e9000 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0x2669357e9000 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0x26693a7d3860 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0x26693a016d40 from unloaded dso, skipping
__cxa_thread_call_dtors: dtr 0x26693ac5db80 from unloaded dso, skipping
The following comment from cxa_thread_atexit_impl.c seems relevant:
C++11 introduces the thread_local scope (like __thread with some
additions). As a key-feature it should support non-trivial
destructors, registered with __cxa_thread_atexit() to be executed
at the thread termination.The implemention keeps a _Thread_local list of destructors per each
thread, and calls __cxa_thread_call_dtors() on each thread's exit
to do cleanup. For a thread calling exit(3), in particular, for
the initial thread returning from main(), we call
__cxa_thread_call_dtors() inside exit().It could be possible that a dynamically loaded library, use
thread_local variable but is dlclose()'d before thread exit. The
destructor of this variable will then try to access the address,
for calling it but it's unloaded, so it'll crash. We're using
__elf_phdr_match_addr() to detect and prevent such cases and so
prevent the crash.
Meta
I can't reproduce this on latest stable, just latest nightly so far.
$ rustc --version --verbose
rustc 1.77.0-nightly (5bd5d214e 2024-01-25)
binary: rustc
commit-hash: 5bd5d214effd494f4bafb29b3a7a2f6c2070ca5c
commit-date: 2024-01-25
host: x86_64-unknown-freebsd
release: 1.77.0-nightly
LLVM version: 17.0.6
$ uname -imrs
FreeBSD 14.0-RELEASE-p3 amd64 GENERIC