SIGSEGV on Netbsd

[AlexanderSchuetz97]

There appears to be threading problems on netbsd.

libloading causes a segfault when running cargo test.
The segfault is sporadic, it only happens about 80% of times.

To run the tests without segfaults one has to pass "-- --test-threads=1" and disable the one test that itself spawn 16 threads.

uname -a from a physical netbsd machine where this occured:

NetBSD nbsd10 10.0 NetBSD 10.0 (GENERIC) #0: Thu Mar 28 08:33:33 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

It is reproducible in a VM too aswell as with different versions of netbsd.

If further investigation concludes that this is indeed a threading problem then
a potencial solution to this would be to have a global lock (std) or spinlock (no-std) for netbsd.
Let me know what you think about this.

This is very low priority for me because I have a global spinlock around libloading for all platforms in all of my code anyways.
I only ran into this when executing libloading's own tests.

[nagisa]

What's the stacktrace?

If I had to guess, I'd blame dlerror on netbsd not being thread-safe (last I checked.) In regular use where there aren't any errors there should be no problems, but libloading test suite does incur quite some errors and I imagine that netbsd's implementation of libc might not be happy to see multiple concurrent calls to dlerror (or maybe even dlsym).

We used to have a lock in a distant past for this, but it turned out to be very opportunistic as well, e.g. it wouldn't do much to help if there were multiple versions of libloading in use concurrently, or if dlerror/dlsym was used from e.g. foreign code.

That said, I was under an impression that the current implementation of get would at least largely mitigate the problems here... But I guess I can see why it might not for certain implementations of dlsym (but that now would be squarely a bug in libc)...

[AlexanderSchuetz97]

Core was generated by `functions-89581b'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000700e2320d82c in ?? ()
[Current thread is 1 (process 26956)]
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file /root/rust_libloading/target/debug/deps/functions-89581be220f61e90.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) bt
#0  0x0000700e2320d82c in ?? ()
#1  0x00000000d30a57ea in std::sys::pal::unix::stack_overflow::thread_info::with_current_info<(), std::sys::pal::unix::stack_overflow::imp::signal_handler::{closure_env#0}> () at library/std/src/sys/pal/unix/stack_overflow/thread_info.rs:62
#2  std::sys::pal::unix::stack_overflow::imp::signal_handler () at library/std/src/sys/pal/unix/stack_overflow.rs:115
#3  <signal handler called>
#4  0x0000700e2320a247 in ?? ()
#5  0x0000700e228d67fb in extent_register_impl.constprop () from /usr/lib/libc.so.12
#6  0x0000700e228dce15 in je_extent_alloc_wrapper () from /usr/lib/libc.so.12
#7  0x0000700e2290587f in arena_bin_malloc_hard () from /usr/lib/libc.so.12
#8  0x0000700e22906b34 in je_arena_tcache_fill_small () from /usr/lib/libc.so.12
#9  0x0000700e228b1866 in je_tcache_alloc_small_hard () from /usr/lib/libc.so.12
#10 0x0000700e2290dfce in calloc () from /usr/lib/libc.so.12
#11 0x00000000d303a741 in alloc::alloc::alloc_zeroed () at library/alloc/src/alloc.rs:177
#12 alloc::alloc::Global::alloc_impl () at library/alloc/src/alloc.rs:189
#13 alloc::alloc::{impl#1}::allocate_zeroed () at library/alloc/src/alloc.rs:256
#14 alloc::boxed::{impl#1}::try_new_zeroed_in<std::sync::mpmc::list::Block<test::event::CompletedTest>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:582
#15 alloc::boxed::{impl#1}::new_zeroed_in<std::sync::mpmc::list::Block<test::event::CompletedTest>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:544
#16 alloc::boxed::{impl#0}::new_zeroed<std::sync::mpmc::list::Block<test::event::CompletedTest>> () at library/alloc/src/boxed.rs:307
#17 std::sync::mpmc::list::Block::new<test::event::CompletedTest> () at library/std/src/sync/mpmc/list.rs:73
#18 std::sync::mpmc::list::Channel::start_send<test::event::CompletedTest> () at library/std/src/sync/mpmc/list.rs:208
#19 std::sync::mpmc::list::Channel::send<test::event::CompletedTest> () at library/std/src/sync/mpmc/list.rs:410
#20 std::sync::mpmc::Sender::send<test::event::CompletedTest> () at library/std/src/sync/mpmc/mod.rs:395
#21 0x00000000d30757fe in std::sync::mpsc::Sender::send<test::event::CompletedTest> () at library/std/src/sync/mpsc.rs:608
#22 test::run_test_in_process () at library/test/src/lib.rs:686
#23 test::run_test::{closure#0} () at library/test/src/lib.rs:592
#24 0x00000000d3039c75 in test::run_test::{closure#1} () at library/test/src/lib.rs:622
#25 std::sys::backtrace::__rust_begin_short_backtrace<test::run_test::{closure_env#1}, ()> () at library/std/src/sys/backtrace.rs:158
#26 0x00000000d303d35a in std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure#0}<test::run_test::{closure_env#1}, ()> () at library/std/src/thread/mod.rs:559
#27 core::panic::unwind_safe::{impl#23}::call_once<(), std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<test::run_test::{closure_env#1}, ()>> () at library/core/src/panic/unwind_safe.rs:272
#28 std::panicking::catch_unwind::do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<test::run_test::{closure_env#1}, ()>>, ()> () at library/std/src/panicking.rs:589
#29 std::panicking::catch_unwind<(), core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<test::run_test::{closure_env#1}, ()>>> () at library/std/src/panicking.rs:552
#30 std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<test::run_test::{closure_env#1}, ()>>, ()> () at library/std/src/panic.rs:359
#31 std::thread::{impl#0}::spawn_unchecked_::{closure#1}<test::run_test::{closure_env#1}, ()> () at library/std/src/thread/mod.rs:557
#32 core::ops::function::FnOnce::call_once<std::thread::{impl#0}::spawn_unchecked_::{closure_env#1}<test::run_test::{closure_env#1}, ()>, ()> () at library/core/src/ops/function.rs:253
#33 0x00000000d30a68ef in alloc::boxed::{impl#28}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:1971
#34 std::sys::pal::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/pal/unix/thread.rs:107
#35 0x0000700e2320c89f in ?? ()
#36 0x0000000000000000 in ?? ()

Note quite inside libloading.
First guess is that we corrupted the allocator with some call. dlerr is proabably not a bad guess.

Naturally a lock does nothing if theres multiple versions of libloading in the binary. (The lock would have to be moved to its own crate where you never increment the version of). And yes you cant do anything if someone calls dlopen/dlsym/dlerr randomly via libc, but that is obvious.

If its indeed dlerr then not calling dlerr on platforms where this problem occurs would also be an idea no?

[nagisa]

If its indeed dlerr then not calling dlerr on platforms where this problem occurs would also be an idea no?

That'd be an option to consider, it would effectively require finding out on which platforms dlsym returning a genuine NULL is not a thing (e.g. on glibc systems this is possible due to IFUNC.) On these platforms we could avoid calling dlerror entirely (or avoid calling it twice the way we do now.)

(Still does not make us 100% in the clear necessarily though. dlsym necessarily interacts with dlerror state in order to set the error upon failure and a straightforward implementation of doing so is makes dlsym MT-unsafe too.)

[AlexanderSchuetz97]

I think the lock in the extra crate (conditional for platforms that are known to cause problems like now netbsd) is at least in my opinion the best solution.

[nagisa]

Looks like dlsym implementation does hold the lock for the entire duration, including while it is setting a new error message, so concurrent calls to dlsym are fine.

That said, looking at how it implements dlerror, there hardly seem any ways for it to interact with the allocator so destructively (since it does not appear interact with the allocator itself, unless xvsnprintf does(?).) We do allocate a new buffer for the error message, but the worst that can really happen here is just copying a possibly malformed data into a predetermined length buffer (and then later deallocating that same buffer).

So there may be something else going on too...

[nagisa]

I see a bunch of different stack traces here:

fini…

* 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 #4: 0x00000000e10814d2 functions-2f1dc930a7f8944e`libloading::os::unix::Library::close::_$u7b$$u7b$closure$u7d$$u7d$::hf66096e39d010098 at mod.rs:366:29
    frame #5: 0x00000000e10811b8 functions-2f1dc930a7f8944e`libloading::os::unix::with_dlerror::h49e9ae0844e04c7f(closure={closure_env#0} @ 0x000075c01c1dfb10, error=(functions-2f1dc930a7f8944e`core::ops::function::FnOnce::call_once::h4d591ac8a4ac1c2d at function.rs:250)) at mod.rs:61:5
    frame #6: 0x00000000e1080fe7 functions-2f1dc930a7f8944e`libloading::os::unix::Library::close::ha828672addda8c6b(self=Library @ 0x000075c01c1dfb38) at mod.rs:364:22
    frame #7: 0x00000000e1081ec7 functions-2f1dc930a7f8944e`libloading::safe::Library::close::h00ec4882ef0ca0ca(self=Library @ 0x000075c01c1dfba0) at safe.rs:163:16
    frame #8: 0x00000000e1033c92 functions-2f1dc930a7f8944e`functions::manual_close_many_times::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h1049330cf3e81efa((null)={closure_env#0} @ 0x000075c01c1dfc37) at functions.rs:368:25
    frame #9: 0x00000000e102b4d6 functions-2f1dc930a7f8944e`std::sys::backtrace::__rust_begin_short_backtrace::he061382c9e8f47dc(f={closure_env#0} @ 0x000075c01c1dfc56) at backtrace.rs:158:18
    frame #10: 0x00000000e101d406 functions-2f1dc930a7f8944e`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h60a37e0a2f1b36ad at mod.rs:559:17
    frame #11: 0x00000000e102b181 functions-2f1dc930a7f8944e`_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h0995fc3d0e32cc5e(self=<unavailable>, (null)=<unavailable>) at unwind_safe.rs:274:9
    frame #12: 0x00000000e102f2e0 functions-2f1dc930a7f8944e`std::panicking::catch_unwind::do_call::hf49c64daf0c22e69(data="\U00000004") at panicking.rs:590:40
    frame #13: 0x00000000e101d6eb functions-2f1dc930a7f8944e`__rust_try + 27
    frame #14: 0x00000000e101d073 functions-2f1dc930a7f8944e`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h7ce34b21950f0369 [inlined] std::panicking::catch_unwind::he062e44f37de6eeb(f=AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<functions::manual_close_many_times::{closure#0}::{closure_env#0}, ()>> @ 0x000075c01c1dfdf0) at panicking.rs:553:19
    frame #15: 0x00000000e101cfc8 functions-2f1dc930a7f8944e`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h7ce34b21950f0369 [inlined] std::panic::catch_unwind::hfef77f8051cb3421(f=AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<functions::manual_close_many_times::{closure#0}::{closure_env#0}, ()>> @ 0x000075c01c1dfdf0) at panic.rs:359:14
    frame #16: 0x00000000e101cfc8 functions-2f1dc930a7f8944e`std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h7ce34b21950f0369 at mod.rs:557:30
    frame #17: 0x00000000e102394e functions-2f1dc930a7f8944e`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h14fb83eac3b36071((null)=0x000075c0232f9120, (null)=<unavailable>) at function.rs:250:5
    frame #18: 0x00000000e1094eaf functions-2f1dc930a7f8944e`std::sys::thread::unix::Thread::new::thread_start::hb82ecdf5ff85e676 [inlined] _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h89157a1940bed6ba at boxed.rs:1985:9
    frame #19: 0x00000000e1094ea7 functions-2f1dc930a7f8944e`std::sys::thread::unix::Thread::new::thread_start::hb82ecdf5ff85e676 at unix.rs:126:17
    frame #20: 0x000075c02340c89f libpthread.so.1`pthread__create_tramp + 90
    frame #21: 0x000075c022a930e0 libc.so.12
    frame #22: 0x000075c02340e199 libpthread.so.1`pthread__makelwp + 188
    frame #23: 0x000075c02340cddb libpthread.so.1`pthread_create + 472
    frame #24: 0x00000000e10950d8 functions-2f1dc930a7f8944e`std::sys::thread::unix::Thread::new::h052daa02a37ee1a5 at unix.rs:108:20
    frame #25: 0x00000000e101caa4 functions-2f1dc930a7f8944e`std::thread::Builder::spawn_unchecked_::hdf5b0e96bbe22090(self=<unavailable>, f={closure_env#0} @ 0x000075c021fdefa4, scope_data=Option<alloc::sync::Arc<std::thread::scoped::ScopeData, alloc::alloc::Global>> @ 0x000075c021fdedc0) at mod.rs:598:30
    frame #26: 0x00000000e101c19e functions-2f1dc930a7f8944e`std::thread::Builder::spawn_unchecked::hd6a87fc1990ff261(self=<unavailable>, f={closure_env#0} @ 0x000075c021fdf1df) at mod.rs:467:37
    frame #27: 0x00000000e101c167 functions-2f1dc930a7f8944e`std::thread::spawn::hf5fdfc1a0ae818d8(f={closure_env#0} @ 0x000075c021fdf277) at mod.rs:729:29

and after commenting out the manual_close_many_times:

symlook

* thread #1, stop reason = signal SIGSEGV
  * 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 #6: 0x000078b9f440c8a7 libpthread.so.1`pthread__create_tramp + 98
    frame #7: 0x000078b9f3a930e0 libc.so.12
    frame #8: 0x000078b9f440e199 libpthread.so.1`pthread__makelwp + 188
    frame #9: 0x000078b9f440cddb libpthread.so.1`pthread_create + 472
    frame #10: 0x000000004f4950d8 functions-2f1dc930a7f8944e`std::sys::thread::unix::Thread::new::h052daa02a37ee1a5 at unix.rs:108:20
    frame #11: 0x000000004f473521 functions-2f1dc930a7f8944e`test::run_test::h2117d05cace83e37 [inlined] std::thread::Builder::spawn_unchecked_::h8355bdbd1a85b419 at mod.rs:598:30
    frame #12: 0x000000004f47326d functions-2f1dc930a7f8944e`test::run_test::h2117d05cace83e37 [inlined] std::thread::Builder::spawn_unchecked::hb298b52f79d37a8f at mod.rs:467:37
    frame #13: 0x000000004f47326d functions-2f1dc930a7f8944e`test::run_test::h2117d05cace83e37 [inlined] std::thread::Builder::spawn::ha5088034dc0d6195 at mod.rs:399:23
    frame #14: 0x000000004f47326d functions-2f1dc930a7f8944e`test::run_test::h2117d05cace83e37 at lib.rs:637:27

and

signal handler exploding

* thread #1, stop reason = signal SIGSEGV
  * frame #0: 0x00006fc4ec5843f9
    frame #1: 0x000000004d093fdd functions-2f1dc930a7f8944e`std::sys::pal::unix::stack_overflow::imp::signal_handler::h98e5c8cf173292fe [inlined] std::sys::pal::unix::stack_overflow::thread_info::with_current_info::h64a867802c195b15 at thread_info.rs:62:16
    frame #2: 0x000000004d093fd7 functions-2f1dc930a7f8944e`std::sys::pal::unix::stack_overflow::imp::signal_handler::h98e5c8cf173292fe at stack_overflow.rs:115:13

are what show up. SIGSEGVs persist even after dlerror is commented out:

dtor stuff again

* thread #1, stop reason = signal SIGSEGV
  * 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
    frame #6: 0x00000000e0c810ae functions-ea96e183da206d8c`_$LT$libloading..os..unix..Library$u20$as$u20$core..ops..drop..Drop$GT$::drop::h7b5dfd4d1b4f1e7a(self=0x000073c4a8def558) at mod.rs:388:13
    frame #7: 0x00000000e0c80f5b functions-ea96e183da206d8c`core::ptr::drop_in_place$LT$libloading..os..unix..Library$GT$::hb7565fd203f996b9((null)=0x000073c4a8def558) at mod.rs:804:1
    frame #8: 0x00000000e0c24c9b functions-ea96e183da206d8c`core::ptr::drop_in_place$LT$libloading..safe..Library$GT$::h18d6020e758b1392((null)=0x000073c4a8def558) at mod.rs:804:1
    frame #9: 0x00000000e0c3226c functions-ea96e183da206d8c`functions::as_filename_test::he5399bca506d755e(path=&std::ffi::os_str::OsStr @ 0x000073c4a8def5d8, with_interior_nulls=&std::ffi::os_str::OsStr @ 0x000073c4a8def5e8) at functions.rs:126:5
    frame #10: 0x00000000e0c20e64 functions-ea96e183da206d8c`functions::test_as_filename_osstr::h483c72cff2087c81 at functions.rs:82:5
    frame #11: 0x00000000e0c33847 functions-ea96e183da206d8c`functions::test_as_filename_osstr::_$u7b$$u7b$closure$u7d$$u7d$::h3c58ef474cc18232((null)=0x000073c4a8def746) at functions.rs:80:28
    frame #12: 0x00000000e0c23e96 functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once::h8a5239f24f7dd0e4((null)={closure_env#0} @ 0x000073c4a8def746, (null)=<unavailable>) at function.rs:250:5
    frame #13: 0x00000000e0c5db1b functions-ea96e183da206d8c`test::__rust_begin_short_backtrace::h81c317e5a8464ed6 [inlined] core::ops::function::FnOnce::call_once::hda908633b29c6c2a at function.rs:250:5
    frame #14: 0x00000000e0c5db19 functions-ea96e183da206d8c`test::__rust_begin_short_backtrace::h81c317e5a8464ed6 at lib.rs:663:18
    frame #15: 0x00000000e0c73805 functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba [inlined] test::run_test_in_process::_$u7b$$u7b$closure$u7d$$u7d$::h435cc0c1de87ed9f at lib.rs:686:74
    frame #16: 0x00000000e0c73800 functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba [inlined] _$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::haa60161b668156ec at unwind_safe.rs:274:9
    frame #17: 0x00000000e0c73800 functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba [inlined] std::panicking::catch_unwind::do_call::h107463394d4ff9e0 at panicking.rs:590:40
    frame #18: 0x00000000e0c737eb functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba [inlined] std::panicking::catch_unwind::h5acce90920297159 at panicking.rs:553:19
    frame #19: 0x00000000e0c737eb functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba [inlined] std::panic::catch_unwind::hc24749e35fd6ad73 at panic.rs:359:14
    frame #20: 0x00000000e0c737eb functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba [inlined] test::run_test_in_process::h1b07a0f9ccb45ab4 at lib.rs:686:27
    frame #21: 0x00000000e0c737c0 functions-ea96e183da206d8c`test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h889c9ed9a054a5ba at lib.rs:607:43
    frame #22: 0x00000000e0c4a035 functions-ea96e183da206d8c`std::sys::backtrace::__rust_begin_short_backtrace::h521ebbdf0726571b [inlined] test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h49aee60cc079bf9b at lib.rs:637:41
    frame #23: 0x00000000e0c49fb9 functions-ea96e183da206d8c`std::sys::backtrace::__rust_begin_short_backtrace::h521ebbdf0726571b at backtrace.rs:158:18
    frame #24: 0x00000000e0c4d72a functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 [inlined] std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h98ec532ba386b3cf at mod.rs:559:17
    frame #25: 0x00000000e0c4d71b functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 [inlined] _$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h18cb29d2701b80df at unwind_safe.rs:274:9
    frame #26: 0x00000000e0c4d71b functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 [inlined] std::panicking::catch_unwind::do_call::h578dc67c6a1c3e6e at panicking.rs:590:40
    frame #27: 0x00000000e0c4d705 functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 [inlined] std::panicking::catch_unwind::hdd9b4f9619993c47 at panicking.rs:553:19
    frame #28: 0x00000000e0c4d705 functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 [inlined] std::panic::catch_unwind::h14db0ee5263b659d at panic.rs:359:14
    frame #29: 0x00000000e0c4d705 functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 [inlined] std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h882dc45e75cce3ba at mod.rs:557:30
    frame #30: 0x00000000e0c4d6b4 functions-ea96e183da206d8c`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h995c26a64e522e55 at function.rs:250:5
    frame #31: 0x00000000e0c9389f functions-ea96e183da206d8c`std::sys::thread::unix::Thread::new::thread_start::hb82ecdf5ff85e676 [inlined] _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h89157a1940bed6ba at boxed.rs:1985:9
    frame #32: 0x00000000e0c93897 functions-ea96e183da206d8c`std::sys::thread::unix::Thread::new::thread_start::hb82ecdf5ff85e676 at unix.rs:126:17
    frame #33: 0x000073c4aae0c89f libpthread.so.1`pthread__create_tramp + 90
    frame #34: 0x000073c4aa4930e0 libc.so.12
    frame #35: 0x000073c4aae0e199 libpthread.so.1`pthread__makelwp + 188

---

not dropping any libraries (commenting out dlclose) makes the sigsegvs go away. This smells a bit like #5, although there is no TLS involvement here.

[AlexanderSchuetz97]

That is rather unfortunate. I also dont drop Library (mem::forget) in my code so that must be why I didnt see this. Maybe dlclose is not threadsafe on netbsd? no... that would be very stupid.

Ive also lookedat this osx issue, perhaps the drop should be made noop on platforms where it crashes on dlclose? I know this is bad too, its just an idea. For Musl libc on linux dlclose itself is a noop so this would not be unprecedented.

[nagisa]

no... that would be very stupid.

There are many much more widely used implementations where dlclose would do a wrong thing in various specific situations. This is the first time I see it happen without TLS involvement though, but it also does not surprise me much.