Repository navigation
[RISCV] Check failed: (trampoline_pos - fixup_pos) <= kMaxBranchOffset. #67274
Description
Version
24.22.2
Platform
Linux 6.12.115+deb13.1-riscv64
Subsystem
No response
What steps will reproduce the bug?
Run jest --ci -u of module deep-for-each, for example.
How often does it reproduce? Is there a required condition?
Not always. Usually fails the first time, and not the second time !
What is the expected behavior? Why is that the expected behavior?
- jest --ci -u
PASS test/test.js
✓ should not call fn on primitive input (30 ms)
✓ should iterate object entries recursively (40 ms)
✓ should iterate arrays recursively (14 ms)
✓ should iterate array/objects recursively (18 ms)
✓ should use the up to date value (in case the forEach callback modified it) (11 ms)
✓ should makethisequal to the subject on the iterator (8 ms)
Test Suites: 1 passed, 1 total
Tests: 6 passed, 6 total
Snapshots: 10 passed, 10 total
Time: 2.345 s
What do you see instead?
See also #60895
+ jest --ci -u
jest-haste-map: Haste module naming collision: deep-for-each
The following files share their name; please adjust your hasteImpl:
* <rootDir>/package.json
* <rootDir>/.pc/fix-for-jest-29.patch/package.json
`isModuleDeclaration` has been deprecated, please migrate to `isImportOrExportDeclaration`
at isModuleDeclaration (file:///usr/share/nodejs/@babel/types/lib/index.js:1967:3)
at PluginPass.Program (/usr/share/nodejs/babel-plugin-lodash/lib/index.js:81:46)
RUNS test/test.js
#
# Fatal error in , line 0
# Check failed: (trampoline_pos - fixup_pos) <= kMaxBranchOffset.
#
#
#
#FailureMessage Object: 0x3f991f9470
----- Native stack trace -----
1: 0x3f9ebeb388 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
2: 0x3f9fc772a8 V8_Fatal(char const*, ...) [/usr/lib/riscv64-linux-gnu/libnode.so.137]
3: 0x3f9fbe686c [/usr/lib/riscv64-linux-gnu/libnode.so.137]
4: 0x3f9fd5cd34 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
5: 0x3f9fd61bce [/usr/lib/riscv64-linux-gnu/libnode.so.137]
6: 0x3f9ff4e928 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
7: 0x3f9ff4eb3c [/usr/lib/riscv64-linux-gnu/libnode.so.137]
8: 0x3f9ff5a808 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
9: 0x3f9f2704ba [/usr/lib/riscv64-linux-gnu/libnode.so.137]
10: 0x3f9f2b8328 v8::internal::OptimizingCompileTaskExecutor::CompileNext(v8::internal::Isolate*, v8::internal::LocalIsolate&, v8::internal::TurbofanCompilationJob*) [/usr/lib/riscv64-linux-gnu/libnode.so.137]
11: 0x3f9f2b8552 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
12: 0x3f9f0db278 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
13: 0x3f9ebef808 [/usr/lib/riscv64-linux-gnu/libnode.so.137]
14: 0x3fa245d332 [/usr/lib/riscv64-linux-gnu/libc.so.6]
15: 0x3fa24a988c [/usr/lib/riscv64-linux-gnu/libc.so.6]
Trace/breakpoint trap
Additional information
No response
Activity
kapouer commentedon Nov 5, 2026
Nota Bene: this happens on the debian build of nodejs.
It also happens when building node-babel7 (the debian package).
On the other hand, nodejs ci tests (sequential/parallel/ and so on) pass (with caveats but nothing weird) on riscv64.
sxa commentedon Nov 5, 2026
Can you clarify which hardware you're running this on? It doesn't surprise me that there are still issues - especially back to node 24 :-)
Bear in mind that riscv64 is currently an experimental platform with no guarantees (and also 24.22.0 and later are even more broken than what you're seeing in our builds, so Debian presumably have applied a fix for that.
kapouer commentedon Nov 5, 2026
Yes, indeed, we applied two patches:
Some features fail on riscv64, all right, that's fair.. Other things, which used to work in previous node 24, now fail.
kapouer commentedon Nov 5, 2026
Also I could reproduce on a Processor: Hifive Unmatched, Memory: 16G.