Repository navigation
linux x64 release binary fails to exec on WSL1 #63735
Description
Version
v24.16.0 (also reproduces on every v23.x and v24.x release; does not reproduce on v22.x)
Platform
Any **WSL1** distro. WSL2 is unaffected.
Subsystem
No response
What steps will reproduce the bug?
curl -LO https://nodejs.org/dist/v24.16.0/node-v24.16.0-linux-x64.tar.gz
tar xf node-v24.16.0-linux-x64.tar.gz
./node-v24.16.0-linux-x64/bin/node --versionHow often does it reproduce? Is there a required condition?
Always, needs WSL1 distro
What is the expected behavior? Why is that the expected behavior?
node should exec and run normally on WSL1, as it did on v22.x. The 2MB p_align carries no runtime benefit for the Node executable today:
- Current executable is of type
ET_EXECwith fixedp_vaddr. The kernel maps eachPT_LOADat its hard-coded address. - The
--use-largepagesfeature performs its hugepage remap at runtime; it never readsp_align.
So the lpstub PT_LOAD advertising p_align = 0x200000 is unnecessary, and clamping it to the page size (0x1000) is behavior-neutral for the runtime while restoring WSL1 compatibility.
What do you see instead?
cannot execute binary file: Exec format error
Additional information
The linux x64 binary ships a PT_LOAD segment (containing the lpstub section used by the --use-largepages feature) whose p_align is 2 MB:
# readelf -lW node-v24.16.0 (offending segment)
Type Offset VirtAddr ... Flg Align
LOAD 0x2c00000 0x0000000003000000 ... R E 0x200000 <-- p_align = 2 MiB
#16198 introduced the section alignment (sh_addralign) for the code mover and its been there for a while. The regression started recently where the program headers started respecting it due to toolchain bump,
| Node | Official linux-x64 toolchain | GNU ld |
lpstub segment p_align |
|---|---|---|---|
| v22.x | RHEL 8 with gcc-toolset-10 |
binutils 2.35 | 0x1000 (works on WSL1) |
| v23.x | RHEL 8 with gcc-toolset-12 |
binutils 2.38 | 0x200000 (rejected) |
| v24.x | RHEL 8 with gcc-toolset-12 |
binutils 2.38 | 0x200000 (rejected) |
binutils commit 74e315dbfe5, first released in binutils 2.38 added a code path in assign_file_positions_for_load_sections that, for a section whose alignment
exceeds maxpagesize (on x86-64 maxpagesize is 0x1000), stamps the segment's p_align to the section alignment. Under binutils 2.35 the segment's p_align was unconditionally maxpagesize (0x1000).
Kernel 5.10+ ce81bb256a22 respects the large p_align segment values for PIE binaries but it doesn't do any rejection in other cases. However, WSL1's binfmt_elf seems to reject any PT_LOAD whose p_align exceeds the system page size.
WSL is not a Tier 1 platform, thought I would raise this here for awareness and if there was interest to have a link time fix after seeing microsoft/WSL#8151. For VSCode remote server where I encountered this, applied a similar solution https://github.com/microsoft/vscode/pull/319355/changes
Activity
joyeecheung commentedon Jun 3, 2026
cc @nodejs/build
richardlau commentedon Jun 3, 2026
node/BUILDING.md
Lines 140 to 146 in 7b1b943
Does it still occur on Node.js 26 where we've switched the toolchain to clang/llvm?
deepak1556 commentedon Jun 3, 2026
It does repro with v26.3.0, IIUC the linker has not been switched with the clang toolchain, its still gnu ld right ? Even with lld this will repro https://godbolt.org/z/oqvaK4bGj , the linkers are doing the right thing. The question is more about does Node.js want to keep the unused p_align that breaks WSL1 support or override it ?
cylonchau commentedon Jun 12, 2026
i try node22 and node24.0 ~ node 24.16 also have this issue
build,src: make --use-largepages a no-op
build,src: make --use-largepages a no-op
build,src: make --use-largepages a no-op