Segmentation fault on worker exit

[mohd-akram]

Version

v26.2.0

Platform

Darwin Mohameds-Mini.lan 25.5.0 Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:26 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T8132 arm64

Subsystem

No response

What steps will reproduce the bug?

package.json:

{
 "type": "module",
 "dependencies": {
 "better-sqlite3": "12.10.0",
 "typeorm": "1.0.0"
 }
}

main.js:

import { Worker } from "worker_threads";
const worker = new Worker("./job.js", {});

job.js:

import { isMainThread } from "worker_threads";

import { DataSource } from "typeorm";

async function main() {
 const ds = await new DataSource({
 type: "better-sqlite3",
 database: 'test.db',
 }).initialize();
 throw new Error("test failure");
}

if (!isMainThread) await main();

Run node main.js

How often does it reproduce? Is there a required condition?

Every time.

What is the expected behavior? Why is that the expected behavior?

Does not crash with segmentation fault.

What do you see instead?

Segmentation fault.

Additional information

Thread 7 Crashed:: WorkerThread
0 ??? 	 0x1272b6e88 ???
1 node 	 0x102675db4 v8::internal::GlobalHandles::InvokeFirstPassWeakCallbacks() + 376
2 node 	 0x1026e8538 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*) + 820
3 node 	 0x1026f4bd8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags, v8::internal::PerformHeapLimitCheck, v8::internal::PerformIneffectiveMarkCompactCheck)::$_1::operator()() const + 512
4 node 	 0x1026f49c0 void heap::base::Stack::SetMarkerAndCallbackImpl<v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags, v8::internal::PerformHeapLimitCheck, v8::internal::PerformIneffectiveMarkCompactCheck)::$_1>(heap::base::Stack*, void*, void const*) + 40
5 node 	 0x102efa7a0 PushAllRegistersAndIterateStack + 40
6 node 	 0x1026e5970 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags, v8::internal::PerformHeapLimitCheck, v8::internal::PerformIneffectiveMarkCompactCheck) + 400
7 node 	 0x1026a0ea0 v8::internal::CppHeap::StartDetachingIsolate() + 76
8 node 	 0x1026f00d8 v8::internal::Heap::StartTearDown() + 32
9 node 	 0x102649110 v8::internal::Isolate::Deinit() + 168
10 node 	 0x102648f88 v8::internal::Isolate::Deinitialize(v8::internal::Isolate*) + 100
11 node 	 0x1023be838 node::MultiIsolatePlatform::DisposeIsolate(v8::Isolate*) + 28
12 node 	 0x10242a83c node::worker::WorkerThreadData::~WorkerThreadData() + 208
13 node 	 0x1024277ac node::worker::Worker::Run() + 736
14 node 	 0x10242ab98 node::worker::Worker::StartThread(v8::FunctionCallbackInfo<v8::Value> const&)::$_0::__invoke(void*) + 80
15 libsystem_pthread.dylib 	 0x185225c58 _pthread_start + 136
16 libsystem_pthread.dylib 	 0x185220c1c thread_start + 8

[arijitchhatui]

This is not a nodejs issue, rather typeorm and better-sqlite3 version issue.
But typeorm officialy supports only <= 11.x better-sqlite3 so during worker/isolate teardown it must have caused native cleanup lifecycle mismatch.
This can be solved on
-- Node v26.0.0
-- TypeORM ^0.3.24
-- better-sqlite3 ^11.0.0

[mohd-akram]

better-sqlite3 ^11.0.0

This version doesn't build with Node.js 26. Tried the versions you mentioned with Node.js 24 and the crash happens there as well. It also can't be a TypeORM issue because TypeORM doesn't use native code.

[arijitchhatui]

But you have to change the typeorm version as well as better-sqlite3 version only then it will succeed

[aduh95]

If you can't reproduce without external dependencies, chances are that is not a Node.js issue, and it should be reported to those dependencies issue trackers instead. If you're able to demonstrate the segmentation fault without any dependency / native addon, we can reopen.

[mohd-akram]

Well it seems to happen with this example from the official docs. This is the modified main.js:

const { isMainThread, Worker } = require('worker_threads');

if (!isMainThread) {
 const addon = require('./build/Release/binding');

 // Create some garbage
 const arr = [];
 for (let i = 0; i < 1e5; i++) arr.push(`${i}`.repeat(100));

 new addon.MyObject(10);

 // Should not segfault
 throw new Error('exit');
} else {
 const worker = new Worker(__filename);
 worker.on('error', () => {});
}

Same issue as #43534. Workaround is to require the addon once in the main thread to prevent it from being dlclosed prematurely.