René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"sea: --build-sea linux-arm64 output fails on 16 KiB and 64 KiB page kernels","articleBody":"### Version\n\nv26.12.1. The regression started in v26.9.0. v26.8.2 works.\n\n### Platform\n\nLinux arm64 with a 16 KiB or 64 KiB page kernel. Examples are Raspberry Pi 5 with its default kernel, Asahi Linux on Apple Silicon, and Docker Sandbox or arm64 VMs on Apple Silicon. The stock `node` binary runs on these hosts. Only `node --build-sea` output fails.\n\n### Subsystem\n\nsingle-executable / sea\n\n### What steps will reproduce the bug?\n\nUse the official linux-arm64 tarball for v26.12.1.\n\nCreate `main.js`:\n\n```js\nconsole.log(\"hello from sea\", process.version);\n```\n\nCreate `sea.json`:\n\n```json\n{\"main\":\"main.js\",\"output\":\"hello\",\"disableExperimentalSEAWarning\":true}\n```\n\nRun `node --build-sea sea.json`. Then run `./hello` on Linux 6.12.107+deb13-arm64-16k, where `getconf PAGESIZE` is 16384.\n\n### How often does it reproduce? Is there a required condition?\n\nIt always reproduces. The required condition is a linux-arm64 host with a 16 KiB or 64 KiB page kernel.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`./hello` should print `hello from sea v26.12.1`. The stock `node` binary runs on the same host, and a SEA built with v26.8.2 runs there.\n\n### What do you see instead?\n\n```\n$ ./node --version          # stock v26.12.1\nv26.12.1\n$ ./hello   # built with v26.8.2\nhello from sea v26.8.2\n$ ./hello   # built with v26.12.1\nSegmentation fault          # exit 139\n```\n\nThe v26.12.1 build fails the same way on Ubuntu's 6.8.0-147-generic-64k kernel (64 KiB pages). On Raspberry Pi 5 and Fedora Asahi Remix hosts, `strace` shows `execve(...) = -1 EINVAL`, and `ld-linux-aarch64.so.1 --list` says \"ELF load command address/offset not page-aligned\".\n\n`readelf -lW hello` for the v26.12.1 output (excerpt):\n\n```\n  PHDR  0x6dad000 0x00000000071ad000 ... 0x0002a0 0x0002a0 R   0x8\n  LOAD  0x000000  0x0000000000400000 ... 0x41d390 0x41d390 R   0x10000\n  LOAD  0x420000  0x0000000000820000 ... 0x29d82f0 0x29d82f0 R E 0x10000\n  LOAD  0x2e00000 0x0000000003200000 ... 0x3eda298 0x3eda298 R   0x10000\n  LOAD  0x6cdee00 0x00000000070eee00 ... 0x0bdb00 0x0bdb00 RW  0x10000\n  LOAD  0x6dad000 0x00000000071ad000 ... 0x000508 0x000508 R   0x1000\n  LOAD  0x8faf000 0x000000001015d000 ... 0x001000 0x001000 R   0x1000\n```\n\nThe v26.8.2 output has no extra PHDR LOAD. Its SEA note LOAD is at offset 0x8dde000 and vaddr 0x10dde000, with align 0x10000.\n\n### Additional information\n\n#65564 added a call to `relocate_phdr_table(PHDR_RELOC::BSS_END)` in `src/node_sea_bin.cc` for non-PIE (`ET_EXEC`) executables, and the official Linux binaries are non-PIE. On linux-arm64, the relocated program header table sits at vaddr 0x71ad000 on a 4 KiB boundary, right after `.bss` ends at 0x71ac900, so it shares a 16 KiB page with the RW segment at 0x70eee00. The SEA note LOAD has file offset 0x8faf000 and vaddr 0x1015d000, which are not congruent mod 16 KiB. Kernels with a page size larger than 4 KiB refuse to map such segments. The test from that PR, `test/sea/test-build-sea-elf-segments.js`, checks at the host page size, and CI hosts use 4 KiB pages, so it did not catch this.\n\nA possible fix is to align the new segments to 64 KiB on aarch64, as the linker already does for the existing segments, or to skip the BSS_END relocation there. The test should also check at 64 KiB.\n\nT3 Code hit this after bumping its SEA CLI to Node 26.12.1: https://github.com/pingdotgg/t3code/issues/23433\n\n---\n\nInvestigated and drafted with AI coding agents, directed and reviewed by @t3dotgg. The reproduction above was run as shown.\n\nDrafted alongside Opus 5.5 and Muse Wonder Full (pls don't be mad at me Matteo)","author":{"url":"https://github.com/t3dotgg","@type":"Person","name":"t3dotgg"},"datePublished":"2026-10-27T08:30:45Z","url":"https://github.com/nodejs/node/issues/67048"}