fix(allocator): fix segfault on Linux MUSL with fixed-size allocators#22388
Conversation
Merging this PR will not alter performance
Comparing Footnotes
|
There was a problem hiding this comment.
Pull request overview
This PR addresses a Linux MUSL segfault when freeing fixed-size Arena allocations used for Oxlint JS plugins by switching Unix platforms to an over-allocation strategy that avoids 4 GiB-aligned allocation requests.
Changes:
- Document the MUSL allocator/free segfault and reference the upstream discussion/issue.
- Consolidate non-Windows fixed-size arena allocation under a single Unix implementation that uses the “over-allocate + pick half” alignment trick.
- Remove the prior Linux-specific fixed-size allocator implementation.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| crates/oxc_allocator/src/arena/fixed_size/unix.rs | Adds MUSL-specific context to the Unix over-allocation workaround documentation. |
| crates/oxc_allocator/src/arena/fixed_size/mod.rs | Updates platform strategy docs and switches module routing to use unix for all non-Windows targets. |
| crates/oxc_allocator/src/arena/fixed_size/linux.rs | Removes the previous Linux direct high-alignment allocation implementation. |
Comments suppressed due to low confidence (1)
crates/oxc_allocator/src/arena/fixed_size/unix.rs:19
- The Openwall link looks incomplete (it points to the day index). Linking to the specific MUSL thread/message referenced in the PR description (e.g. ending in
/1) would make this reference more stable and directly actionable for future debugging.
41a56e3 to
28567af
Compare
28567af to
d3d2249
Compare
Merge activity
|
…#22388) Fixes #22339. #22088 introduced separate implementations for different platforms for creating a fixed-size `Arena` (used in Oxlint JS plugins). The Linux implementation assumed that Linux's system allocator can handle allocation requests with 4 GiB alignment. Unfortunately, it turns out there is an arithmetic overflow bug in Linux MUSL, where the allocation request succeeds, but then produces a segfault when the allocation is later freed. https://www.openwall.com/lists/musl/2026/05/12/1 Work around this by using the same workaround we already have for MacOS - over-allocate 4 GiB with 2 GiB alignment, and then use either the top or bottom half of the allocation - one of which is guaranteed to be 4 GiB-aligned. We could have applied the fix only on Linux MUSL, and left other Linux implementation as is, but it seems simpler to have one unified implementation. Many thanks to @kalvenschraut for finding and tracking down the cause of this bug.
d3d2249 to
66d77eb
Compare
### 🚀 Features - bc91a17 codegen: Expose `Codegen::with_source_type` method (#22432) (camc314) ### 🐛 Bug Fixes - 5ac7e79 minifier: Drop unused-var-init pure IIFEs and preserve annotation for downstream (#22349) (Dunqing) - 4ab57eb allocator: Fixed-size allocators use `VirtualAlloc` on Windows (#22124) (overlookmotel) - 66d77eb allocator: Fix segfault on Linux MUSL with fixed-size allocators (#22388) (overlookmotel) - b8fbc1f transformer/object-rest-spread: Correct scope id when moving bindings (#22419) (camc314) - 18edc2c codegen: Keep `Object.defineProperty` property name as plain string in minify (#22400) (Dunqing) - dda33de transformer/explicit-resource-management: Align lexical binding scopes (#22320) (camc314) - 8e79de8 transformer: Preserve for-await statement bodies (#22361) (camc314) - 0cba210 transformer/class: Replace `new.target` in static blocks (#22360) (camc314) - 67ab1c9 transformer/es2018/for-await: Hoist for-await generated bindings (#22355) (camc314) - c3ceb4a transformer/object-rest-spread: Use hoisted scope for `for-of` temp refs (#22347) (camc314) ### ⚡ Performance - 73a9043 allocator/bitset: Avoid temp heap `String` allocation (#22403) (camc314) - 8b2f4f9 transformer/object-rest-spread: Collect `Vec<SymbolId` over `Vec<BindingIdentifier>` (#22418) (camc314) - 83679ea parser: Split TriviaBuilder::handle_token hot/cold paths (#22415) (Boshen) - 2c7d781 codegen: Inline identifier-name accessors (#22411) (Boshen) - 618bc76 diagnostics: Inline `OxcDiagnosticInner` to avoid heap allocation (#22406) (Boshen) - 0b4e158 parser: Reserve cap `2` for sequence expressions vec (#22374) (camc314) - 5f3bdd0 codegen: Add `#[inline]` to `code`, `code_len` (#22373) (camc314) Co-authored-by: overlookmotel <557937+overlookmotel@users.noreply.github.com>
- oxlint 1.63.0 → 1.66.0 - oxlint-tsgolint 0.22.1 → 0.23.0 - oxc-parser 0.131.0 → 0.132.0 Picks up the v1.65.0 Linux MUSL fix for the fixed-size allocator (oxc-project/oxc#22388 — backing fix for the SIGABRT panic at `crates/oxc_allocator/src/pool/fixed_size.rs:112` we hit in Vercel Sandbox) and Windows `VirtualAlloc` fix (#22124), plus the new built-in rules from v1.65/1.66 (no-noninteractive-element-to-interactive-role, no-noninteractive-element-interactions, control-has-associated-label, no-implicit-globals, no-implied-eval, id-match, no-object-type-as-default-prop, no-unstable-nested-components, import/newline-after-import, jsx-a11y-x support). All 1404 tests pass. Co-authored-by: Cursor <cursoragent@cursor.com>

Fixes #22339.
#22088 introduced separate implementations for different platforms for creating a fixed-size
Arena(used in Oxlint JS plugins). The Linux implementation assumed that Linux's system allocator can handle allocation requests with 4 GiB alignment.Unfortunately, it turns out there is an arithmetic overflow bug in Linux MUSL, where the allocation request succeeds, but then produces a segfault when the allocation is later freed. https://www.openwall.com/lists/musl/2026/05/12/1
Work around this by using the same workaround we already have for MacOS - over-allocate 4 GiB with 2 GiB alignment, and then use either the top or bottom half of the allocation - one of which is guaranteed to be 4 GiB-aligned.
We could have applied the fix only on Linux MUSL, and left other Linux implementation as is, but it seems simpler to have one unified implementation.
Many thanks to @kalvenschraut for finding and tracking down the cause of this bug.