Segfault when running dlopen/dlclose (on NixOS 21.11)

[mfsch]

Calling dlopen/dlclose from within Julia appears to cause a segfault on NixOS 21.11 with Julia 1.6.3 (current version of the julia-bin package). I’m not sure whether this is a problem of Julia or of NixOS, but since the julia-bin package is a pretty straightforward installation of the julialang.org binaries I thought I’d try Julia first. I have tried to reproduce it on Ubuntu 18.04 and 20.04 but didn’t manage to trigger the error. However, the latest 1.7.0 binaries from julialang.org also trigger the crash on NixOS.

I’m also not sure if this is related to #34726 since getenv appears in the backtrace.

Steps To Reproduce

I originally ran into this issue when building the MPI.jl package, but I’ve managed to narrow it down to some dlopen/dlclose calls. The following command reliably generates a segfault for me. In interactive sessions, the segfault appears directly after the dlclose call, but adding sleep with an integer argument allows me to trigger it directly with -e (and for some reason, sleep with a float argument does not trigger it?).

$ /nix/store/h3chs763ab8g7xrww42ak25fcg9anz27-julia-bin-1.6.3/bin/julia -e 'Base.Libc.Libdl.dlopen("/nix/store/fqbhnxw5f0bqy7gfvvwbh8inh53nl7n7-openmpi-4.1.2/lib/libmpi") |> Base.Libc.Libdl.dlclose; sleep(0)'
Segmentation fault (core dumped)

Backtrace from gdb:

Thread 1 "julia" received signal SIGSEGV, Segmentation fault.
0x00007ffff7e175fd in getenv () from /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libc.so.6
(gdb) bt
#0  0x00007ffff7e175fd in getenv () from /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libc.so.6
#1  0x00007ffff7e100f4 in __dcigettext () from /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libc.so.6
#2  0x00007ffff7fc07d4 in dlerror () from /nix/store/z56jcx3j1gfyk4sv7g8iaan0ssbdkhz1-glibc-2.33-56/lib/libdl.so.2
#3  0x00007ffff7036b1c in jl_dlsym (handle=0x7ffff7ffe1f0, symbol=0x7fffdbeb9100 <_j_str367> "jl_switch", value=0x7fffffffa9a8, throw_err=1) at /buildworker/worker/package_linux64/build/src/dlload.c:282
#4  0x00007ffff6fa0f68 in jl_load_and_lookup (f_lib=<optimized out>, f_name=0x7fffdbeb9100 <_j_str367> "jl_switch", hnd=<optimized out>) at /buildworker/worker/package_linux64/build/src/runtime_ccall.cpp:63
#5  0x00007fffdba95d9c in jlplt_jl_switch_32678.clone_1 () from /nix/store/h3chs763ab8g7xrww42ak25fcg9anz27-julia-bin-1.6.3/lib/julia/sys.so
#6  0x00007fffdb8e74a4 in julia_try_yieldto_32675 () at task.jl:700
#7  0x00007fffdb8e839b in julia_wait_22171 () at task.jl:770
#8  0x00007fffdbd41663 in julia_wait_22135 () at condition.jl:106
#9  0x00007fffdb6ea97c in japi1__trywait_20860 () at asyncevent.jl:111

Versions

julia> versioninfo()
Julia Version 1.6.3
Commit ae8452a9e0 (2021-09-23 17:34 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, skylake)

$ nixos-version
21.11.334247.573095944e7 (Porcupine)

[mfsch]

I just came across open-mpi/ompi#10142 and remembered that I reported something similar in this issue here. Without digging deeper, it seems likely that this is the same issue and is therefore a) not a Julia issue and b) fixed now.