Abort "Lazy deopt after a fast API call with return value is unsupported" in Buffer.byteLength called from maybePrepareFinalChunk / res.end(string) #66870

Activity

1. jakesalvesen commented on Oct 20, 2026

   

   jakesalvesen

   on Oct 20, 2026

   Author

   More actions

   Adding the reproduction attempts so triage does not have to repeat them.

   Environment matched to the crashing run (Node 26.10.0, Windows 11 x64): I started the same Vite 8.3.4 dev server on the exact node-26.10.0 binary (verified via ExecutablePath) and requested the same 43.8 MB pre-bundled chunk the crashing stack shows (send$1 receives String[17354770], which matches the 17,416,067-byte source chunk, and maybePrepareFinalChunk receives String[43640789] after Vite appends the inline source map):

   • 3,000 keep-alive requests over 4 sockets, 125,335 MiB served in 161 s - no abort, server still answering afterwards.
   • 240 fresh-connection requests, 10,027 MiB - no abort.
   • 3,000 res.end() calls on a synthetic 1 MiB string alternating with Buffer and res.end(string, 'utf8') to keep the call site polymorphic - no abort.
   • 300 res.end() responses of a 43.6 MB string - no abort.
   • The same on v26.12.0 with the same results, plus --deopt-every-n-times=3 to force deopts at deopt points.

   So volume alone is not the trigger. Differences from the crashing run that I could not reproduce locally:

   1. The crashing process had been up for ~10 minutes serving 261 Playwright tests, i.e. hundreds of distinct module URLs and a browser sending real navigation/fetch traffic - not one URL in a loop. Call-site polymorphism in send$1 and the Vite middleware chain is therefore much broader than in my loop.
   2. Sustained allocation pressure from repeatedly materializing ~43 MB strings, with GC/compaction active, plus several browser workers in parallel.
   3. Linux x64 in CI versus Windows x64 locally.

   If helpful, the minimal shape I would try on a Linux runner is: one node:http server that responds with res.end(bigString) where msg._header is still unset (so maybePrepareFinalChunk runs), several concurrent clients requesting a rotating set of distinct URLs, and the server pinned to v26.10.0. I am happy to run that against a candidate build if you tell me which one - I just cannot execute Linux runners from here.
2. jakesalvesen commented on Oct 20, 2026

   

   jakesalvesen

   on Oct 20, 2026

   Author

   More actions

   Linux results, so this does not get assumed to be a Windows-only artifact - it is not reproducible here either, even on Linux with the crashing Node build.

   Setup: WSL2 guest (Ubuntu 24.04.5, kernel 6.18.54.1-microsoft-standard-WSL2, 24 vCPU) running the official node-v26.10.0-linux-x64 build, i.e. the same version as the crashing CI run.

   Run 1 - synthetic server that reproduces the failing shape exactly (res.end(string) with msg._header unset so maybePrepareFinalChunk calls Buffer.byteLength), 8 concurrent keep-alive clients over 2,000 requests / 61 GB, rotating between the crashing payload sizes (43,640,789 and 17,354,770 chars), a Buffer variant, a HEAD variant and a small variant, with a timer allocating ~24 MB every 250 ms to keep GC/compaction active: no abort.

   Run 2 - same, but the large payload is a ConsString (code + sourceMappingURL prefix + base64), which is what Vite's send() actually hands to res.end() after appending the inline source map, rather than a flat 'x'.repeat(n): 2,400 requests / 73 GB: no abort.

   I also tried to run the real Vite 8.3.4 dev server inside the Linux guest. That failed for a mundane reason: this checkout's node_modules was installed on Windows, so rolldown has only the win32 native binding and the Linux server cannot start (Cannot find module '@rolldown/binding-linux-x64-gnu'). A npm ci inside the guest would be needed to run that variant, which I did not do.

   So the trigger needs more than the call shape, the payload sizes, the cons-string flattening, volume, concurrency and GC pressure. My best remaining hypothesis is that it depends on the state of the large Vite middleware chain after minutes of varied traffic (deep, polymorphic call sites feeding send()), or on a specific deopt point in that chain, rather than on Buffer.byteLength itself. If a collaborator can share the --trace-deopt output or a core dump from a recurrence, I can narrow it from there.
3. jakesalvesen commented on Oct 20, 2026

   

   jakesalvesen

   on Oct 20, 2026

   Author

   More actions

   One more diagnostic that may save time: on Linux with the crashing Node build, I ran the synthetic server under --trace-deopt --deopt-every-n-times=2 while a client drove 300 mixed requests (43.6 MB cons string, 17.35 MB string, Buffer, HEAD, small). Result: 54 deopt events were logged, none in maybePrepareFinalChunk / _http_outgoing / Buffer.byteLength, and no abort.

   That suggests the abort needs maybePrepareFinalChunk itself to be running optimized TurboFan code when the lazy deopt is requested - in my loop it never tiered up (the frame is only reached once per response, and my sockets were dominated by socket-write work rather than that function). A loop would probably have to drive that exact function into optimized code thousands of times while something invalidates it, which is consistent with a long, varied CI session rather than a tight loop.

   If that matches your reading, the actionable ask on the reporter side is --trace-deopt (or --trace-opt --trace-deopt) enabled on the CI runner so the next recurrence records which deopt triggered the bailout, and I can wire that into our pipeline.
4. lazerg commented on Oct 20, 2026

   

   lazerg

   on Oct 20, 2026

   Contributor

   More actions

   It's partly a V8 limitation and partly on Node's side. The abort itself is deliberate in V8: since 517cf1b a lazy deopt after a fast API call that returns a value just crashes, and that TODO (crbug.com/418936518) is still open on V8 main, so a V8 update won't fix it yet. What likely triggers the deopt is Node's FastByteLengthUtf8: both String::ValueView and Utf8LengthV2 flatten a concatenated string, which means allocating ~87 MB on the JS heap inside the fast call, something V8's fast API rules say fast callbacks shouldn't do. A GC there can invalidate the optimized caller, which would explain why it only shows up after long runs under memory pressure. Until the fast path avoids that, your Buffer.from(content) workaround is the right fix.
5. jakesalvesen commented on Oct 20, 2026

   

   jakesalvesen

   on Oct 20, 2026

   Last edited by jakesalvesen

   Author

   More actions

   Thanks, that matches what the stack shows and gives me something testable.

   Confirming the flatten: with the server on a tight heap (--max-old-space-size=192) and a fresh code + sourceMappingURL prefix + base64 ConsString per response (43,640,789 chars, same lengths as the crash), GC runs inside Buffer.byteLength constantly - Scavenge 130.2 (131.7) -> 88.5 (90.1) MB, allocation failure every ~20 ms across 4,000 requests. So the ~43 MB flatten allocation and the mid-fast-call GC are both reproduced.

   Still no abort, and the crash stack suggests why: frames 1-3 (byteLength, maybePrepareFinalChunk, end) are all [bytecode=... offset=...], while only frames 4-5 (send$1, viteTransformMiddleware) carry [pc=0x...]. So the optimized frame that V8 invalidates is the Vite caller, not Node's own _http_outgoing frame, and the lazy deopt point that trips is in that optimized caller. Reproducing it therefore needs an optimized JS caller performing the res.end(hugeConsString) call under heap pressure, not just Node internals under pressure. I can try to shape a synthetic caller to match (a hot, optimized function that calls res.end(consString)), but I wanted to check with you first: does that reading match the intended constraint, or should the optimized caller be irrelevant because the deopt point is attributed to the callee's frame?

   Either way this settles the practical question for us: the Buffer.from(content) workaround stays until V8 lands crbug.com/418936518 or the fast path stops allocating for cons strings. If a Node-side mitigation is welcome in the meantime (for example skipping the fast path for large or non-flat strings in maybePrepareFinalChunk, or deferring _contentLength to the write path), I am willing to prepare the patch and the test.
6. jakesalvesen commented on Oct 20, 2026

   

   jakesalvesen

   on Oct 20, 2026

   Author

   More actions

   One check that may save you time: this is not already fixed on main. The implementation moved out of lib/_http_outgoing.js into lib/internal/http/outgoing.js, and the same call is still there:

   // lib/internal/http/outgoing.js, current main
   function maybePrepareFinalChunk(msg, chunk, encoding) {
     ...
     if (!msg._header) {
       msg._contentLength = typeof chunk === 'string' ?
         Buffer.byteLength(chunk, encoding) : chunk.byteLength;

   So the flatten-inside-fast-call path survives the refactor, and the abort stays reachable until either V8 implements the deopt or Node stops computing a string length through the fast path there.