[Bug]: Native binding segfault on require() + clean exit (regression 2.0.0 → 2.0.1, win32-arm64-msvc)

[robrobrobrob]

System Info

OS | Windows 11 Pro (ARM) — 10.0.26200.8246
Node | v22.22.2 (arm64)
Rspack | 2.0.1 (regression introduced here)
Last working version | 2.0.0
Architecture | aarch64-pc-windows-msvc

Details

Bisect
Tested against @rspack/binding-win32-arm64-msvc versions in isolation:

Version Result
1.0.0 exit 0 ✓
1.5.0 exit 0 ✓
1.7.11 exit 0 ✓
2.0.0-rc.0 exit 0 ✓
2.0.0-rc.3 exit 0 ✓
2.0.0 exit 0 ✓
2.0.1 segfault, exit 139 ✗
Same regression also breaks SWC minifier
In a real project, SwcJsMinimizerRspackPlugin crashes mid-build on the same platform with the same access violation:

// minimal hello.js entry, mode: production
new rspack.SwcJsMinimizerRspackPlugin()
Crashes silently mid-build on 2.0.1; works fine on 2.0.0.

Likely cause
The 2.0.1 release notes mention chore: upgrade swc_core from 64 to 65. Likely candidates: a Drop impl introduced in swc_core 0.65, or an arm64-windows codegen path that's hit during native teardown / minifier execution.

Workaround
Pin to @rspack/core@2.0.0 + @rspack/cli@2.0.0 (binding follows).

Reproduce link

No response

Reproduce Steps

Reproduction
mkdir rspack-segfault && cd rspack-segfault
npm init -y
npm install @rspack/binding-win32-arm64-msvc@2.0.1
node -e "require('@rspack/binding-win32-arm64-msvc'); console.log('about to exit')"
Expected: exit 0
Actual: prints about to exit, then Segmentation fault and exits 139 (STATUS_ACCESS_VIOLATION / 0xC0000005)

[CPunisher]

Can you please provide the rspack-segfault project?

[robrobrobrob]

Hey @CPunisher — there's no separate project; the reproduction is literally the four shell commands in the issue body. After npm init -y + the single npm install, the directory contains nothing but a package.json with @rspack/binding-win32-arm64-msvc@2.0.1 as a dependency, and the crash fires from the one-line node -e "require('@rspack/binding-win32-arm64-msvc'); console.log('about to exit')".

[robrobrobrob]

Repo here: https://github.com/robrobrobrob/rspack-segfault — both crashes reproduced on Windows 11 ARM64 + Node 22 arm64. Run via node directly (yarn translates the segfault to exit 1):

• node repro-require.js — bare require + console.log + exit teardown crash from the issue body.
• node gen-ts-entries.js && node node_modules/@rspack/cli/bin/rspack build — SwcJsMinimizerRspackPlugin mid-build crash. Generator drops 2,500 small TS entries; the SWC minifier dies on them. With optimization.minimize: false the build emits all 2,500 files cleanly, so the minifier is the trigger.

A custom phase-tracer plugin (sync fs.appendFileSync per lifecycle hook so the trace survives the native crash) shows the build dies between processAssets stage 399 and stage 400 — exactly Compilation.PROCESS_ASSETS_STAGE_OPTIMIZE_SIZE, where the minimizer taps. Likely related to the swc_core 64 → 65 bump in 2.0.1.

NODE_OPTIONS=--report-on-fatalerror doesn't fire on either — both are below where Node can intercept.

[robrobrobrob]

Root cause: mimalloc 3.3.1 atomics bug, not rspack

After bisecting the v2.0.0 ↔ v2.0.1 diff, this looks like an upstream mimalloc bug that snuck in via #13827, not anything in rspack's own code.

Evidence

1. The only platform-relevant runtime change in v2.0.0 → v2.0.1 is in crates/rspack_allocator/Cargo.toml from chore(deps): update patch crates #13827 (commit 120fea54d):

   -mimalloc = { workspace = true, features = ["local_dynamic_tls", "v3"] }
   +mimalloc = { workspace = true, features = ["local_dynamic_tls"] }

   The PR description ("remove stale mimalloc v3 feature") suggests the intent was not to change behavior. But mimalloc-rs 0.1.50 had simultaneously flipped v3 to the default and removed the explicit feature — so the bundled mimalloc C version moved from a working 3.2.x line to 3.3.1. Cargo.lock confirms: libmimalloc-sys 0.1.44 → 0.1.47, mimalloc 0.1.48 → 0.1.50.

2. mimalloc upstream bug matches exactly: microsoft/mimalloc#1277 — "mimalloc v3.3.0 / v3.3.1 fails on Windows ARM 64" — same exit code: 0xc0000005, STATUS_ACCESS_VIOLATION, same arch. Regression from 3.2.8.

3. Fix is already merged upstream: microsoft/mimalloc@60a1f3b (Apr 24) — "update MSVC C atomics wrapper to implement loads as readonly and use more optimal arm instructions (issue test(packages/rspack): module type override #1277)" — shipped in mimalloc v3.3.2 (Apr 29).

4. Why both crash sites have the same 0xC0000005: mimalloc is the #[global_allocator] (crates/rspack_allocator/src/lib.rs), so every alloc/free in the Node process goes through the broken MSVC atomics wrapper. It fires during TLS/arena teardown at process exit (the require(); console.log repro), and during rayon worker thread teardown after SwcJsMinimizerRspackPlugin completes (the mid-build crash at stage 400). The swc_core 64→65 bump in chore: upgrade swc_core from 64 to 65 #13857 is unrelated.

5. main HEAD is still affected — Cargo.lock still pins libmimalloc-sys 0.1.47 + mimalloc 0.1.50 (mimalloc C 3.3.1).

Two fix paths

Long-term (in flight): Filed purpleprotocol/mimalloc_rust#164 to bump the bundled mimalloc to v3.3.2. Once that merges and libmimalloc-sys cuts a release, rspack just needs to bump Cargo.lock.

Short-term (one-line, doesn't wait on anyone): opt rspack's allocator into the v2 feature on Windows. mimalloc 2.3.x doesn't have #1277:

[target.'cfg(all(target_os = "windows", target_arch = "aarch64"))'.dependencies]
mimalloc = { workspace = true, features = ["v2"] }

(Or target_os = "windows" broadly if you'd rather not branch on arch.)

Repro (matches the v2.0.0 vs v2.0.1 boundary)

npm i @rspack/binding-win32-arm64-msvc@2.0.1
node -e "require('@rspack/binding-win32-arm64-msvc'); console.log('about to exit')"
# prints "about to exit", then exit 139 / 0xC0000005

npm i @rspack/binding-win32-arm64-msvc@2.0.0
# same script exits 0