parcel-bundler / parcel-bundler/lightningcss
[1.29.x][regression] segfault when require()-ed from a worker thread in Node 22/Linux
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 7.7k
- Forks
- 302
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the entry.cjs and worker.cjs reproducer using Node 22 on Linux, then compare its behavior with lightningcss 1.28.x and 1.29.x. Use the reported GDB backtrace as an initial debugging point; done means requiring lightningcss from the worker thread no longer segfaults on the reported environment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, node.js, rust
- Domain
- devtools, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100