[1.29.x][regression] segfault when require()-ed from a worker thread in Node 22/Linux

[AviVahl]

Reproduced locally (fedora 41/kernel 6.12.8/node 22.13.0) and on our Linux CI machines (ubuntu-based, I believe).

Steps to reproduce:

mkdir lightning-segfault
cd lightning-segfault
npm init -y
npm i lightningcss
echo "const { Worker } = require('worker_threads'); new Worker(require.resolve('./worker.cjs'));" > entry.cjs
echo "require('lightningcss')" > worker.cjs
node entry.cjs

1.28.x works
1.29.x prints Segmentation fault (core dumped) and crashes the process

Basic steps with GDB say:

Thread 13 "node" received signal SIGSEGV, Segmentation fault.

(gdb) backtrace
#0  0x00007fffce5a0ef0 in ?? ()
#1  0x00007ffff7a79e30 in __nptl_deallocate_tsd () from /lib64/libc.so.6
#2  0x00007ffff7a7cf02 in start_thread () from /lib64/libc.so.6
#3  0x00007ffff7b010cc in __clone3 () from /lib64/libc.so.6

not sure whether the above is useful without additional debug symbols.

[devongovett]

Probably related to this Rust bug: rust-lang/rust#91979. The workaround is to load the native module on the main thread in addition to the worker so that it never gets unloaded.

[AviVahl]

Probably related to this Rust bug: rust-lang/rust#91979. The workaround is to load the native module on the main thread in addition to the worker so that it never gets unloaded.

Appreciate the workaround, even though it won't help our case. We've got code from "repo A" loading other pieces of code from a separate "repo B" without knowing B uses lightningcss in its logic or not.