Crash on startup (SIGSEGV) on Linux/Wayland — fork() in dt_init triggers OpenBLAS blas_thread_shutdown race with GTK style on recentcollect thread

Summary

darktable 5.4.1 reliably SIGSEGVs during GUI startup on Linux/Wayland. The crash is GUI-init specific: launching headless (darktable --library :memory:) runs fine, but the normal GUI launch crashes in dt_init() while building the UI. The backtrace shows a fork() inside dt_init triggering OpenBLAS's blas_thread_shutdown pre-fork handler on the main thread, racing with GTK style-context resolution on another thread (the recent-collections module setting a button label).

This is the Linux counterpart to the closed-as-incomplete #20111 (Windows, no backtrace). Unlike that report, this one includes a full backtrace + coredump.

How to reproduce

1. Launch darktable (GUI) on the system below.
2. It crashes on launch with SIGSEGV before the lighttable appears.

darktable --library :memory: -d common (headless) does not crash — confirming the fault is in GUI initialization, not the library/db.

Backtrace (key frames)

Faulting thread (GTK style on the recent-collections module):

#0  0x0000000000000041 (jump to bad address 0x41)
#6  gtk_style_context_get_style_valist (libgtk-3.so.0)
#7  gtk_style_context_get_style       (libgtk-3.so.0)
#9  gtk_button_set_label              (libgtk-3.so.0)
#10 librecentcollect.so + 0x28a6
...
#20 dt_control_signal_raise           (libdarktable.so)

Main thread (fork during init → OpenBLAS pre-fork handler):

#5  blas_thread_shutdown_  (libopenblas.so.0 + 0xa0f06e)
#6  __run_prefork_handlers (libc.so.6)
#7  __libc_fork            (libc.so.6)
#8  libdarktable.so + 0x1c228c
...
#39 gtk_widget_show        (libgtk-3.so.0)
#40 dt_init                (libdarktable.so + 0xf117f)
#41 /usr/bin/darktable

Several worker threads are parked in blas_thread_shutdown_ (libopenblas) and libnvidia-opencl.so.1.

Likely root cause

dt_init() performs a fork() (e.g. for a helper/version probe) while OpenBLAS worker threads and GTK are already active. OpenBLAS's pthread-based blas_thread_shutdown pre-fork handler is known to race/deadlock when fork() is called from a multithreaded process (OpenBLAS OpenMathLib/OpenBLAS#2270, fix PR #3111). Here it surfaces as a SIGSEGV rather than a hang because a GTK style lookup on the recentcollect thread dereferences a bad pointer (jump to 0x41) concurrently with the fork tear-down.

System

• darktable: 5.4.1-1 (Ubuntu package, amd64)
• OS: Ubuntu 26.04 LTS, kernel 7.0.0-22-generic
• Session: Wayland, KDE Plasma
• OpenBLAS: libopenblas0 0.3.32+ds-5 (pthread variant)
• GTK: 3.24.52-0ubuntu1
• GPU: NVIDIA (OpenCL present in trace), dGPU MUX mode
• Coredump: present (coredumpctl info darktable, 36 MB), available on request

Workaround

Per the #20111 pattern, relaunching after the first-run crash sometimes succeeds. Forcing OpenBLAS single-threaded (OPENBLAS_NUM_THREADS=1 darktable) is a candidate mitigation given the fork-race root cause (untested here — noting for triage).

Notes

Filed at the request of the system owner after the crash was hit opening PNGs. Happy to provide the full coredump, darktable -d all log, or test patches/env-var mitigations.

Start at dt_init in the main-thread backtrace and compare the normal GUI launch with darktable --library :memory:. Inspect the recent-collections path shown by librecentcollect.so, the fork call, and the supplied coredump for the interaction with GTK and OpenBLAS. Done means GUI startup no longer reliably SIGSEGVs on the reported Linux/Wayland setup, with the headless behavior still working.