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

Anthony Mallet <[email protected]>
Newsgroups gmane.os.netbsd.bugs
Organization LAAS/CNRS - Toulouse - France
Message-ID <[email protected]>
Hi,

On Thursday 16 Jul 2026, at 00:03, Taylor R Campbell wrote:
> Can you try the attached patch and see if it works in your complex
> application?

Thanks ! It fixes the recursive behaviour yes.
At least with my quick testing, the application does not deadlock anymore.

Now, I'm back to my original problem though (before your changes,
ld.elf_so around Jan 22 this year), which is a segfault in dclose(),
deterministic, although the backtrace can vary depending on the code or
if I prevent some libraries from dlclos'ing. So it was looking really
similar to the 59751 issue, but it's actually not.

I don't think the application does something wrong. It works under
linux (which is not a reason, but I also inspected the code a
bit). The problem is that it's a really huge code base ...

I not sure how to trace this. Next step is probably compiling
ld.elf_so with debug and step through...

Just FYI, the backtrace of thread 1 is in unloaded code, at one can
see by printing the address _before_ the segfault:

(gdb) b dlclose
(gdb) r
Thread 1 "" hit Breakpoint 1.2, 0x00007f7ff7ef26cb in dlclose ()
   from /usr/libexec/ld.elf_so
(gdb) info sym 0x00007f7ff5c211d0
ament_index_cpp::get_resource(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) + 499 in section .text of /home/tho/openrobots/x86_64-netbsd11/lib/libament_index_cpp.so
(gdb) c
Continuing.

Thread 1 "" hit Breakpoint 1.2, 0x00007f7ff7ef26cb in dlclose ()
   from /usr/libexec/ld.elf_so
(gdb) c
Continuing.
[LWP 998 of process 25222 exited]

Thread 1 "" received signal SIGSEGV, Segmentation fault.
0x00007f7ff5c321d0 in ?? ()
(gdb) thr app all bt

Thread 2 (process 1493):
#0  0x00007f7ff78c126a in _sys___select50 () from /usr/lib/libc.so.12
#1  0x00007f7ff784d24a in __select50 () from /usr/lib/libpthread.so.1
#2  0x00007f7ff7e7dab9 in NotifierThreadProc () from /usr/pkg-2025Q3/lib/libtcl86.so
#3  0x00007f7ff7851383 in ?? () from /usr/lib/libpthread.so.1
#4  0x00007f7ff7917de0 in ?? () from /usr/lib/libc.so.12
#5  0x0000000000200000 in ?? ()
#6  0x0000000000000000 in ?? ()

Thread 1 (process 372):
#0  0x00007f7ff5c211d0 in ?? ()
#1  0x00007f7ff77cbe90 in ?? ()
#2  0x00007f7ff7766780 in ?? ()
#3  0x00007f7fffffd150 in ?? ()
#4  0x00007f7ff5f903e6 in std::destroy_at<rcpputils::SharedLibrary> (__location=0x7f7ff7766780) at /usr/include/g++/bits/stl_construct.h:88
Backtrace stopped: frame did not save the PC
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.