lib/59751: dlclose is not MT-safe depending on the libraries unloaded

[netbsd%kazlauskas.me@localhost]

>Number:         59751
>Category:       lib
>Synopsis:       dlclose is not MT-safe depending on the libraries unloaded
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Nov 08 19:55:00 +0000 2025
>Originator:     Simonas K.
>Release:        10.1
>Organization:
N/A
>Environment:
NetBSD  10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
It looks like unloading dynamically loaded libraries via `dlclose` can result in applications SIGSEGV'ing with all sorts of stack traces such as:

```
* thread #1, stop reason = signal SIGSEGV
  * frame #0: 0x000075c01b8419e0
    frame #1: 0x00007f7eaa205e04 ld.elf_so`_rtld_call_fini_function + 135
    frame #2: 0x00007f7eaa2061bd ld.elf_so`_rtld_unload_object.part.0 + 700
    frame #3: 0x00007f7eaa2074b2 ld.elf_so`dlclose + 233
    ...
```

```
  * frame #0: 0x00007f7f03a07fab ld.elf_so`_rtld_symlook_obj + 619
    frame #1: 0x00007f7f03a083ea ld.elf_so`_rtld_symlook_list + 185
    frame #2: 0x00007f7f03a0889f ld.elf_so`_rtld_symlook_default + 530
    frame #3: 0x00007f7f03a08d4a ld.elf_so`_rtld_find_plt_symdef + 221
    frame #4: 0x00007f7f03a00bc0 ld.elf_so`_rtld_bind + 75
    frame #5: 0x00007f7f03a0082d ld.elf_so`_rtld_bind_start + 29
    ...
```

```
  * frame #0: 0x000073c4aaa10e6f libgcc_s.so.1`__deregister_frame_info_bases + 70
    frame #1: 0x000073c4aa446705 libc.so.12`__do_global_dtors_aux + 85
    frame #2: 0x000073c4aa584919 libc.so.12`_fini + 9
    frame #3: 0x00007f7e90805e04 ld.elf_so`_rtld_call_fini_function + 135
    frame #4: 0x00007f7e9080623d ld.elf_so`_rtld_unload_object.part.0 + 828
    frame #5: 0x00007f7e908074b2 ld.elf_so`dlclose + 233
    ...
```

etc. Not unloading the libraries (i.e. commenting out `dlclose`) makes the SIGSEGVs go away. It seems like this may be related to the fact that the library loaded/unloaded has dtors. In my case the code being tested is a Rust library over dl* primitives (rust_libloading) and the dynamic library used is not especially interesting (e.g. it has just a few pure functions and don't do risky stuff as spawning threads.)
>How-To-Repeat:
* git clone https://github.com/nagisa/rust_libloading
* cargo test
* observe sigsegv (make sure to run on a multi-core system.)

You can comment out the two occurrences of `dlclose` in `src/os/unix/mod.rs` to check that it is indeed `dlclose` that's having a poor interaction with *something*. You can also comment out the code involving `dlerror` to rule out any potential MT-unsafety related issues.

The code for library being loaded and unloaded is available at `src/test_helpers.rs` which can be independently compiled with `rustc src/test_helpers.rs -o test_helpers.so`.
>Fix:
A number of other system library/linker/loader implementations transparently refuse to unload libraries that e.g. register thread locals. An example of this is MacOS. I'm semi-confident that nothing of the sort is happening in `rust_libloading`s tests though and the shared object is extremely straighforward, so something deeper is going on here.

---

P.S. it would be nice if `dlerror` was made MT-safe (by e.g. maintaining a thread-local error buffer.)
P.P.S. I'm just forwarding a bug report made against rust_libloading after some initial investigation. I'm happy to help with brainstorming possible causes.