JSC/Bun segfault with high-volume N-API addon — SCI-specific?

[robert-johansson]

We encounter a segfault when running nbb on Bun (but not Node.js) with a library that creates thousands of N-API-wrapped objects per second (https://github.com/robert-johansson/genmlx).

We've ruled out the native addon (ASAN clean, disabling C++ finalizers doesn't help). We can't reproduce without nbb — pure JS with the same addon at higher scale works fine on Bun.

I wonder if SCI's evaluation model creates any object patterns that interact differently with JSC vs V8 — e.g., closure scoping, interpreter stack management, or how SCI holds references to externally-wrapped values during interpretation.

I'm trying to track down where the issue can be - any thoughts are welcome.

[borkdude]

Doesn't ring a bell to me but if there's anything to fix I'm open to it.
Perhaps also file a repro with bun itself? Have you tried other JS envs like Node.js?

[robert-johansson]

Thanks! Yes, Node.js/V8 works perfectly — that's how we confirmed it's JSC-specific. We also ran AddressSanitizer on the native addon under Node.js — zero memory errors, so the C++ side is clean.

We even disabled the N-API finalizer entirely (just leak memory, never delete anything) and Bun still segfaults. So it's not the addon's destructor logic either.

The pattern: nbb interprets ClojureScript that calls an N-API addon (@frost-beta/mlx, Apple GPU arrays) ~5000 times in a tight loop. We tried reproducing with pure JS calling the same addon at even higher scale (500 particles × 50 steps) on Bun — no crash. But the pure JS version creates far fewer intermediate JS objects per iteration than SCI does (no persistent maps, protocol dispatch, closures, etc.), so it's not a perfect comparison.

Will file with Bun. Thanks for looking at it.

[borkdude]

It might be worth trying in pure JS but in the way SCI implements JS interop. See src/sci/impl/interop.cljc etc.