Repository navigation
single-executable-application-test* fail on Linux ppc64le #59561
Description
This is similar to #59553, but for Linux ppc64le.
#58761 skipped several single-executable-application-test* tests on Linux ppc64le for Node.js 20.19.3 onwards:
- test-single-executable-application
- test-single-executable-application-assets
- test-single-executable-application-assets-raw
- test-single-executable-application-disable-experimental-sea-warning
- test-single-executable-application-empty
- test-single-executable-application-snapshot
- test-single-executable-application-snapshot-and-code-cache
- test-single-executable-application-snapshot-worker
- test-single-executable-application-use-code-cache
There was an attempt to bisect during Node.js 20.19.3, but it was inconclusive (one bisect pointed to a WPT commit, a second bisect pointed to the release commit).
The same tests were skipped for Node.js 22.18.0 in #58914.
We're now seeing similar test failures when we build main with clang (the tests are currently passing when built with gcc).
- sequential.test-single-executable-application
- sequential.test-single-executable-application-assets
- sequential.test-single-executable-application-assets-raw
- sequential.test-single-executable-application-disable-experimental-sea-warning
- sequential.test-single-executable-application-empty
- sequential.test-single-executable-application-snapshot
- sequential.test-single-executable-application-snapshot-and-code-cache
- sequential.test-single-executable-application-snapshot-worker
- sequential.test-single-executable-application-use-code-cache
In these cases the injected binary is crashing (SIGSEGV), e.g.
https://ci.nodejs.org/job/richardlau-node-test-commit-plinux/13/nodes=rhel8-ppc64le/console
17:58:07 not ok 4707 sequential/test-single-executable-application-empty
17:58:07 ---
17:58:07 duration_ms: 10763.88000
17:58:07 severity: fail
17:58:07 exitcode: 1
17:58:07 stack: |-
17:58:07 Copied /home/iojs/build/workspace/richardlau-node-test-commit-plinux/nodes/rhel8-ppc64le/out/Release/node to /home/iojs/node-tmp/.tmp.4706/sea
17:58:07 Injected /home/iojs/node-tmp/.tmp.4706/sea-prep.blob into /home/iojs/node-tmp/.tmp.4706/sea
17:58:07 [process 61879]: --- stderr ---
17:58:07
17:58:07 [process 61879]: --- stdout ---
17:58:07
17:58:07 [process 61879]: status = null, signal = SIGSEGV
17:58:07 /home/iojs/build/workspace/richardlau-node-test-commit-plinux/nodes/rhel8-ppc64le/test/common/child_process.js:98
17:58:07 throw error;
17:58:07 ^
17:58:07
17:58:07 Error: - process terminated with status null, expected 0
17:58:07 - process terminated with signal SIGSEGV, expected null
17:58:07 at Object.<anonymous> (/home/iojs/build/workspace/richardlau-node-test-commit-plinux/nodes/rhel8-ppc64le/test/sequential/test-single-executable-application-empty.js:56:1)
17:58:07 at Module._compile (node:internal/modules/cjs/loader:1737:14)
17:58:07 at Object..js (node:internal/modules/cjs/loader:1870:10)
17:58:07 at Module.load (node:internal/modules/cjs/loader:1469:32)
17:58:07 at Module._load (node:internal/modules/cjs/loader:1289:12)
17:58:07 at TracingChannel.traceSync (node:diagnostics_channel:322:14)
17:58:07 at wrapModuleLoad (node:internal/modules/cjs/loader:238:24)
17:58:07 at Module.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:154:5)
17:58:07 at node:internal/main/run_main_module:33:47 {
17:58:07 command: '/home/iojs/node-tmp/.tmp.4706/sea'
17:58:07 }
17:58:07
17:58:07 Node.js v25.0.0-pre
17:58:07 ...These appear to be consistent crashes and not flakes.
I tried to run one of the injected binaries through lldb, but it wasn't helpful(?):
[iojs@test-osuosl-rhel8-ppc64--le-4 sea]$ lldb ./sea
(lldb) target create "./sea"
Current executable set to '/tmp/sea/sea' (powerpc64le).
(lldb) run
Process 1609342 launched: '/tmp/sea/sea' (powerpc64le)
Process 1609342 stopped
* thread nodejs/postject#1, name = 'sea', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x7fff8a545c18)
frame #0: 0x00007fff8a545c18
error: memory read failed for 0x7fff8a545c00
(lldb) [iojs@test-osuosl-rhel8-ppc64--le-4 sea]$cc @nodejs/single-executable
Activity
richardlau commentedon Aug 21, 2025
Yesterday I opened a PR to skip the tests on
mainfor Linux ppc64le so that we don't break the CI when we switch over to use clang to build: #59563Out of curiosity, I tried running a build with clang CI for #59560 and interestingly the tests all pass with that PR: https://ci.nodejs.org/job/richardlau-node-test-commit-plinux/22/
test: skip sea tests on Linux ppc64le
test: skip sea tests on Linux ppc64le
joyeecheung commentedon Aug 25, 2025
It's unclear to me whether it's related but I bumped into another error when I forgot skip on ppc64le when just adding some tests for loading addons from the SEA #59582
https://ci.nodejs.org/job/node-test-commit-plinux/60507/
My hunch is that maybe some handling is missing somewhere in the SEA building routine for the little endian?
test: skip more sea tests on Linux ppc64le
test: skip more sea tests on Linux ppc64le
test: skip sea tests on Linux ppc64le
test: skip more sea tests on Linux ppc64le
joyeecheung commentedon Nov 9, 2025
I managed to reproduce the symbol not found issue in a docker container and it seems postject is at least corrupting the gnu hash table in some circumstances (e.g. in a Linux arm64 container) - it might be the same cause of the crash on ppc64le #61483
joyeecheung commentedon Dec 24, 2025
It appears #61167 fixes it the GNU hash table corruption issue for me at least on Linux arm64 container - maybe it can also fix it for PPC64LE?
github-actions commentedon Jul 20, 2026
This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Aug 20, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.