sea: keep ELF segments on separate pages in --build-sea output by codebytere · Pull Request #65564 · nodejs/node

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

codebytere · 2026-08-26T14:00:53Z

The sea/* failures on the rhel8-x64 CI hosts (SIGSEGV, empty stderr, https://github.com/nodejs/reliability/blob/main/reports/2026-08-26.md) come with a kernel line, elf segment at ... requested but the memory is mapped already (nodejs/build#4433 (comment)), which is execve refusing the injected executable. When node is not PIE (RHEL toolchains, and the official Linux binaries), LIEF makes room for the new program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across it; when that gap is the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ends inside the next segment's first page. Linux 4.17 to 5.3 and RHEL 8's 4.18 map an executable's segments with MAP_FIXED_NOREPLACE, so the second mapping fails past the point of no return and the process is killed; newer kernels don't check. Which gap is largest depends on section sizes, so it comes and goes from build to build.

This asks LIEF for its after-.bss placement when the executable is ET_EXEC, which leaves every existing segment where the linker put it and gives the header table pages of its own; the output grows by the size of .bss (about 340 KB for node). PIE builds are unchanged. postject makes the same choice in its own copy of LIEF, so test-single-executable-application.js and test_sea_addon, which still inject with it, aren't covered by this.

Tests:

new test/sea/test-build-sea-elf-segments.js asserts no two PT_LOAD segments of a --build-sea executable share a page; test/sea passes
reproduced off CI with a non-PIE node built with RHEL 8's clang whose read-only/read-write gap is the largest: on AlmaLinux 8.10 (4.18.0-553.150.1.el8_10) the SEA built before this change segfaults with the same kernel line and the one built after it runs; both run on a 6.12 kernel

Refs: nodejs/build#4433

Disclosure: the code, test, investigation and this description were written by Claude Code, directed and reviewed by @codebytere.

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com>

nodejs-github-bot · 2026-08-26T14:00:59Z

Review requested:

@nodejs/single-executable

panva

RSLGTM

github-actions · 2026-08-26T14:04:38Z

Fast-track has been requested by @panva. Please 👍 to approve.

sxa · 2026-08-26T14:33:50Z

That's not ideal - merge conflict on the rhel8-x64 machine
https://ci.nodejs.org/job/node-test-commit-linux/72453/nodes=rhel8-x64/console

Attempting a test in the stress job with 100 iterations: rhel8-x64 and rhel9-x64 as we really need the results on rhel8-x64 ASAP.

codecov · 2026-08-26T15:51:29Z

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.06%. Comparing base (7b6b21a) to head (84be637).
⚠️ Report is 23 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_sea_bin.cc	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #65564 +/- ##
=======================================
Coverage 90.05% 90.06% =======================================
Files 751 751 Lines 254420 254423 +3 Branches 47975 47986 +11 =======================================
+ Hits 229121 229148 +27 + Misses 16483 16444 -39 - Partials 8816 8831 +15

Files with missing lines	Coverage Δ
src/node_sea_bin.cc	`41.07% <0.00%> (-0.45%)`	⬇️

... and 35 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

sxa

Annoying (as usual...) but https://ci.nodejs.org/job/node-stress-single-test/nodes=rhel8-x64/848/console which was without this patch seemed to be passing too. But on the basis this has been tested in an environment where it was reproducible I'm approving.

Out of interest, did you manage to come to any conclusion abot what change could have caused this to start going wrong recently given that it doesn't seem to have been package updates?

nodejs-github-bot · 2026-08-26T23:28:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76541/

sxa · 2026-08-26T23:44:21Z

Every so often we get a problem with merge/rebase conflicts and we don't have a permanent fix for it at the moment. This one seems to have triggered it. We've had 3 PR test runs so far and I'm collating these links for my own benefit and because I'm going to try and disable one machine to let this through:

test-pr job	test-commit job	Failures
76521	91260	do-rhel8-x64-1 (multiple merge conflicts) do-rhel9-x64-1 (Makefile conflict) ibm-rhel8-s390x-1 osu-rhel8c-arm64-1 aix73-power9
76529	91268	do-rhel9-x64-1 (multiple merge conflicts) rhel8-x64 passed on do-rhel8-x64-2 ibm-aix-72-2 l1cc-rhel9-s390x-2
76538	71277	ibm-rhel8-x64-3 (Multiple merge conflicts) do-rhel9-x64-1 (Multiple merge conflicts) do-f42-x64-1 ibm-rhel8-s390x-3 (Makefile conflict) ibm-aix72-2

A few notes:

rhel8-s390x tests are all failures with parallel/test-http2-debug so assumed unrelated to this PR
the third PR test row above is not just a re-run of the failures in the second row - it re-run most of the platforms from what I can see including ones that passed so it has re-runrhel8-x64 which failed, but it had already passed in the second one.
The rhel9-x64 merge conflicts is still a problem. All three ran on the same machine which I've now taken offline so the next run will be forced to one of the other two and run a retry of the second job. It's running as per the comment that has just been posted above and the rhel9-x64 job is now executing without merge conflicts - on test-ibm-rhel9-x64-2

Hopefully that new run will get close to a pass although I'll note that between the second and third runs we do have passes on both rhel8-s390x and rhel9-s390x. Similarly for AIX we have passes on both aix72-power9 and aix73-power9](https://ci.nodejs.org/job/node-test-commit-aix/64731/) I'll keep the problematic rhel9/x64 machine offline and perhaps see if I can analyse the workspace on the machine to try and replicate the problem manually. Mentioning nodejs/build#4345 which was a similar situation seen in the past.

nodejs-github-bot · 2026-08-26T23:51:35Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76542/

nodejs-github-bot · 2026-08-27T04:11:44Z

CI: https://ci.nodejs.org/job/node-test-pull-request/76549/

nodejs-github-bot · 2026-08-27T07:00:37Z

Landed in a2bbe4e

When node itself is not position independent (the official Linux binaries, and any build with a toolchain that does not default to PIE), LIEF made room for the extra program header by moving the header table into the largest gap between two PT_LOAD segments and extending the earlier segment across that gap. Whenever the gap it picked was the one between the read-only data and the read-write segment, whose boundary is not page aligned, the extended segment ended inside the first page of the next one. Linux 4.17 to 5.3, and RHEL 8's 4.18 kernel, map an executable's segments with MAP_FIXED_NOREPLACE and refuse the second mapping, so the single executable was killed with SIGSEGV before it ran a single instruction ('elf segment at ... requested but the memory is mapped already' in the kernel log). Which gap is largest depends on section sizes, so roughly one build in three produced such binaries. Ask LIEF to place the table after .bss for non-PIE executables instead, which leaves every existing segment as the linker laid it out; the output grows by the size of .bss. A test checks that no two PT_LOAD segments of a --build-sea executable share a page. Signed-off-by: Shelley Vohr <shelley.vohr@gmail.com> PR-URL: #65564 Refs: nodejs/build#4433 Reviewed-By: Filip Skokan <panva.ip@gmail.com> Reviewed-By: Stewart X Addison <sxa@redhat.com> Reviewed-By: James M Snell <jasnell@gmail.com>

nodejs-github-bot added needs-ci PRs that need a full CI run. single-executable Issues and PRs related to single-executable applications. labels Aug 26, 2026

panva approved these changes Aug 26, 2026
View reviewed changes

panva mentioned this pull request Aug 26, 2026
test: mark platform-specific tests as flaky #65562
Merged

codebytere mentioned this pull request Aug 26, 2026
node-test-commit-linux on 'rhel8-x64' is failing since 2026-08-20 nodejs/build#4433
Closed

MikeMcC399 mentioned this pull request Aug 26, 2026
permission: support URL and Uint8Array as has()/drop() reference #65492
Merged

github-actionsBot removed the request-ci Add this label to start a Jenkins CI on a PR. label Aug 26, 2026

This comment has been minimized.
Sign in to view

MikeMcC399 mentioned this pull request Aug 26, 2026
Single Executable Application tests often fail on RISC-V #61110
Open

panva added the flaky-test Issues and PRs involving tests that fail intermittently in CI. label Aug 26, 2026

sxa approved these changes Aug 26, 2026
View reviewed changes

This comment has been minimized.
Sign in to view

This comment was marked as resolved.
Sign in to view

jasnell approved these changes Aug 27, 2026
View reviewed changes

panva added the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 27, 2026

nodejs-github-bot merged commit a2bbe4e into nodejs:mainAug 27, 2026
97 checks passed

nodejs-github-bot removed the commit-queue PRs queued for automated landing through the Commit Queue. label Aug 27, 2026

This was referenced Aug 27, 2026
Built-In Node has low disk space nodejs/build#4419
Open
Merge conflicts on node-test-commit-* jobs nodejs/build#4445
Open

panva mentioned this pull request Aug 28, 2026
crypto: add a generic MAC API #65553
Closed