What version of Tailwind CSS are you using?
@tailwindcss/oxide and @tailwindcss/oxide-win32-x64-msvc 4.3.3.
What build tool (or framework if it abstracts the build tool) are you using?
The reproduction uses only Node's built-in worker_threads and Oxide. Originally encountered during Expo/Metro Android release builds using UniWind 1.11.0, but those tools are not required to reproduce it.
What version of Node.js are you using?
v24.13.1, win32 x64. The original build also failed on v24.20.0; the isolated results below are specifically from v24.13.1.
What browser are you using?
N/A.
What operating system are you using?
Windows 11 Pro, build 26200, x64. ESET remained enabled during the isolated comparison; no antivirus exclusions or diagnostic preloads were used.
Reproduction URL
https://github.com/bompus/oxide-worker-unload-repro
git clone https://github.com/bompus/oxide-worker-unload-repro.git
cd oxide-worker-unload-repro
npm install
node compare.cjs 20
node repro.cjs runs a single baseline trial. node repro.cjs --retain first loads the same Oxide package in the main thread. Clear any diagnostic/preload NODE_OPTIONS before comparing.
Describe your issue
A Node worker creates a Scanner and scans 100 in-memory HTML strings, then exits naturally. The parent stays alive for another 500 ms. Expected: the scanner produces flex, the worker exits successfully, and the parent exits 0. Actual: the process intermittently exits with 0xC0000005 rather than a JavaScript exception.
The fresh minimal project produced these results from 20 sequential pairs, reversing baseline/retention order on alternate pairs:
| Arm |
Passed |
Access violations |
| Oxide loaded only in worker |
18/20 |
2/20 |
| Same package also loaded in main thread |
20/20 |
0/20 |
Failing baseline trials were 7 and 19, both with process status 3221225477 (0xC0000005), no stdout, and no stderr. This is intermittent: one passing run does not exclude the bug, and these counts are not a general failure-rate claim.
Native evidence from the original build
A locally captured dump of the failing Expo update-resource subprocess yielded:
ExceptionCode: c0000005
ExceptionAddress: <Unloaded_tailwindcss-oxide.win32-x64-msv>+0x212ec6
Parameter[0]: 8 (execute access)
Memory state/protection: MEM_FREE / PAGE_NOACCESS
Failure bucket: SOFTWARE_NX_FAULT_INVALID_POINTER_EXECUTE_c0000005_tailwindcss-oxide.win32-x64-msv!Unloaded
The dump came from the original build, not the minimal reproduction. It establishes an attempt to execute unloaded Oxide code. The remaining stack was not reliable enough to identify a specific Rust function or thread owner. No dump is uploaded here.
Workaround and possible direction
Requiring UniWind's resolved Oxide dependency in the main thread before worker creation passed ten earlier small trials and three alternating full APK builds; one of those three full-build baseline trials crashed. The newly isolated comparison above independently reproduced the same baseline/workaround distinction.
Oxide's scanner uses Rayon's parallel iterators. Native thread lifetime versus library unloading is a plausible mechanism, not yet a symbolically proven identification of the faulting thread. Related discussion: rayon-rs/rayon#1101 and rayon-rs/rayon#1242.
A proposed Windows library-retention fix and regression test are in draft PR #20471. Comparing release binaries built from upstream f723e83 and the patch in another 20 alternating pairs reproduced two baseline access violations and zero patched failures. The regression fixture's explicit library-retention assertion failed 20/20 unmodified runs and passed 20/20 patched runs. The PR documents validation limits, including eight scanner symlink test failures also reproduced on untouched upstream. A process-lifetime pin intentionally keeps the native library mapped until Node exits; it does not implement native thread-pool shutdown.
What version of Tailwind CSS are you using?
@tailwindcss/oxideand@tailwindcss/oxide-win32-x64-msvc4.3.3.What build tool (or framework if it abstracts the build tool) are you using?
The reproduction uses only Node's built-in
worker_threadsand Oxide. Originally encountered during Expo/Metro Android release builds using UniWind 1.11.0, but those tools are not required to reproduce it.What version of Node.js are you using?
v24.13.1, win32 x64. The original build also failed on v24.20.0; the isolated results below are specifically from v24.13.1.
What browser are you using?
N/A.
What operating system are you using?
Windows 11 Pro, build 26200, x64. ESET remained enabled during the isolated comparison; no antivirus exclusions or diagnostic preloads were used.
Reproduction URL
https://github.com/bompus/oxide-worker-unload-repro
node repro.cjsruns a single baseline trial.node repro.cjs --retainfirst loads the same Oxide package in the main thread. Clear any diagnostic/preloadNODE_OPTIONSbefore comparing.Describe your issue
A Node worker creates a Scanner and scans 100 in-memory HTML strings, then exits naturally. The parent stays alive for another 500 ms. Expected: the scanner produces
flex, the worker exits successfully, and the parent exits 0. Actual: the process intermittently exits with0xC0000005rather than a JavaScript exception.The fresh minimal project produced these results from 20 sequential pairs, reversing baseline/retention order on alternate pairs:
Failing baseline trials were 7 and 19, both with process status
3221225477(0xC0000005), no stdout, and no stderr. This is intermittent: one passing run does not exclude the bug, and these counts are not a general failure-rate claim.Native evidence from the original build
A locally captured dump of the failing Expo update-resource subprocess yielded:
The dump came from the original build, not the minimal reproduction. It establishes an attempt to execute unloaded Oxide code. The remaining stack was not reliable enough to identify a specific Rust function or thread owner. No dump is uploaded here.
Workaround and possible direction
Requiring UniWind's resolved Oxide dependency in the main thread before worker creation passed ten earlier small trials and three alternating full APK builds; one of those three full-build baseline trials crashed. The newly isolated comparison above independently reproduced the same baseline/workaround distinction.
Oxide's scanner uses Rayon's parallel iterators. Native thread lifetime versus library unloading is a plausible mechanism, not yet a symbolically proven identification of the faulting thread. Related discussion: rayon-rs/rayon#1101 and rayon-rs/rayon#1242.
A proposed Windows library-retention fix and regression test are in draft PR #20471. Comparing release binaries built from upstream
f723e83and the patch in another 20 alternating pairs reproduced two baseline access violations and zero patched failures. The regression fixture's explicit library-retention assertion failed 20/20 unmodified runs and passed 20/20 patched runs. The PR documents validation limits, including eight scanner symlink test failures also reproduced on untouched upstream. A process-lifetime pin intentionally keeps the native library mapped until Node exits; it does not implement native thread-pool shutdown.