Using fast calls for WASI causes V8 coredump

[TerrorJack]

Version

v19.7.0

Platform

Linux build01 6.0.3 #1-NixOS SMP PREEMPT_DYNAMIC Fri Oct 21 10:39:29 UTC 2022 x86_64 GNU/Linux

Subsystem

wasi

What steps will reproduce the bug?

See https://bugs.chromium.org/p/v8/issues/detail?id=13753 for the minimal repro. V8 upstream has indicated that #43697 is the culprit.

How often does it reproduce? Is there a required condition?

No response

What is the expected behavior?

No response

What do you see instead?

See above.

Additional information

No response

[cjihrig]

cc: @devsnek

[devsnek]

It seems that calling AdjustAmountOfExternalAllocatedMemory triggers a GC :/

I am gonna kick this back to V8 lol

[bnoordhuis]

V8 says they don't consider it a bug so I guess that means node needs to defer the AdjustAmountOfExternalAllocatedMemory() call until a GC-safe point in time, i.e., until after the fast call.

Alternatively / workaround-ishly, src/node_wasi.cc could move away from NgLibMemoryManager to a memory manager that doesn't call AdjustAmountOfExternalAllocatedMemory().

I don't think that AdjustAmountOfExternalAllocatedMemory() makes sense for WASI anyway because its allocations aren't tied to JS objects so best case, it's a no-op, worst case, it makes the GC vacuum more frequently but pointlessly.

[github-actions]

This issue has been marked as stale due to 210 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]

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.

[jonheltonbloom]

Still reproduces on current Node (v22.23.2, x64, Linux), with a real-world workload rather than a synthetic test, and I can confirm the exact mechanism @bnoordhuis diagnosed above.

What I'm running

A WASI-compiled CPython 3.14.7 interpreter (wasm32-wasip1, official Tools/wasm/wasi build, WASI SDK v24), as part of a sandboxed code-execution feature. Not a toy — this is a full interpreter opening its own stdlib files (path_open) during startup/import.

Default flags: segfault

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000013b1af9 in v8::internal::InnerPointerToCodeCache::GetCacheEntry(unsigned long) ()
#1  v8::internal::CommonFrame::IterateTurbofanOptimizedFrame(v8::internal::RootVisitor*) const ()
#2  v8::internal::Isolate::Iterate(v8::internal::RootVisitor*, v8::internal::ThreadLocalTop*) ()
#3  v8::internal::Heap::IterateRoots(...)
#4  v8::internal::MarkCompactCollector::MarkRoots(v8::internal::RootVisitor*) ()
#5  v8::internal::MarkCompactCollector::MarkLiveObjects() ()
#6  v8::internal::MarkCompactCollector::CollectGarbage() ()
#7  v8::internal::Heap::MarkCompact() ()
#8  v8::internal::Heap::PerformGarbageCollection(...)
#9  v8::internal::Heap::CollectGarbage(...)::{lambda()#2}::operator()() const ()
#10 heap::base::Stack::SetMarkerAndCallbackImpl<...>(...)
#11 PushAllRegistersAndIterateStack ()
#12 v8::internal::Heap::CollectGarbage(...)
#13 v8::internal::Heap::ReportExternalMemoryPressure() ()
#14 v8::Isolate::AdjustAmountOfExternalAllocatedMemory(long) ()
#15 node::mem::NgLibMemoryManager<node::wasi::WASI, uvwasi_mem_s>::MallocImpl(unsigned long, void*) ()
#16 uvwasi.resolve_path ()
#17 uvwasi_path_open ()
#18 node::wasi::WASI::WasiFunction<..., &node::wasi::WASI::PathOpen, ...>::FastCallback(...) ()

Exactly the chain from this issue: AdjustAmountOfExternalAllocatedMemory (called via NgLibMemoryManager::MallocImpl from path_open's fast callback) triggers a GC, and GC's stack scan crashes trying to resolve the fast-call trampoline's return address.

--no-allow-allocation-in-fast-api-call: confirms the mechanism, doesn't fix it

Tried this flag hoping V8 would just take the slow path instead. It doesn't avoid the problem — it converts the silent memory corruption into a clean, deliberate abort, which is arguably a better symptom but confirms this is exactly the violation already named here:

# Fatal error in , line 0
# Check failed: !v8_flags.allow_allocation_in_fast_api_call implies !isolate()->InFastCCall().

i.e., the fast call for path_open really is triggering GC from inside a fast C call, and V8 is (correctly) refusing to proceed once that's disallowed rather than corrupting memory. This isn't fixable from the Node/V8-flag side — it confirms @bnoordhuis's read that src/node_wasi.cc needs to stop calling AdjustAmountOfExternalAllocatedMemory() synchronously from the fast path, either by deferring it to a GC-safe point or (per the suggestion above) moving off NgLibMemoryManager for a manager whose accounting doesn't matter for WASI's actual allocation pattern.

src/node_wasi.cc/src/node_mem.h still use NgLibMemoryManager on current main, so nothing has changed here since the original report.

One data point neither prior report established

This is not simply an x86_64-vs-arm64 thing (as #53087's title suggests) — it's more specific than the ISA. I could not reproduce this at all in either of two attempts on a different host:

• Native macOS, arm64, Node 22.23.2 — ran clean.
• node:22-bookworm-slim in a linux/amd64 Docker container, emulated via QEMU on Apple Silicon, same Node version, same 8 MiB stack ulimit — also ran clean.

It only reproduces on GitHub Actions' hosted ubuntu-latest runner (real x86_64 hardware). Whatever the actual trigger condition is, it's closer to real-hardware/kernel/allocator specifics than the instruction set architecture alone.

Ask

This was diagnosed with a clear root cause and two candidate fixes three years ago and closed only by the stale-bot — never actually fixed, and still live in current Node. Given a real interpreter workload (not just a small test case) reliably hits it, could this get reopened/reprioritized? Happy to help test a patch — I have a full CPython WASI build + repro script + both backtraces on hand.

(cross-referencing #53087, which bisected the same root cause to #43697 with a minimal Haskell repro)