Question about fixing Node.js issue #66074 upstream in V8

46 views
Skip to first unread message

eliau elkouby (‫אליהו אלקובי‬‎)

unread,
Sep 21, 2026, 5:08:49 AM (13 days ago) Sep 21
to v8-dev

Hi V8 team,

I’d like to contribute a fix for Node.js issue #66074:

https://github.com/nodejs/node/issues/66074

The issue is a crash when Error.stackTraceLimit is set to a very large value, caused by an integer overflow in the stack trace handling code.

A Node.js maintainer advised me to fix this upstream in V8 first.

I couldn’t find an existing V8 issue for this bug, so I wanted to ask whether I should open a V8 issue first and discuss the proposed fix there, or proceed directly with a CL.

I’m also planning to add a regression test for the overflow case.

Thanks!

Jakob Gruber

unread,
Sep 21, 2026, 8:42:43 AM (13 days ago) Sep 21
to v8-...@googlegroups.com
A short bug report would be great, thanks.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/aacced99-d9a9-4111-a844-56fa4ea3baecn%40googlegroups.com.


eliau....@gmail.com

unread,
Sep 23, 2026, 7:18:45 AM (11 days ago) Sep 23
to v8-...@googlegroups.com, jgr...@chromium.org
Thanks Jakob — filed as https://issues.chromium.org/issues/565047704.

CL: https://chromium-review.googlesource.com/c/v8/v8/+/8426465
(now carries the Bug: line)

Root cause: Error.stackTraceLimit counts frames, but since
https://crrev.com/c/7673818 the raw call site data holds kCount slots per
frame, and CaptureAndSetErrorStack multiplies the limit by kCount before
comparing it against the array length. The uint32_t product wraps for
large limits — from 858993460 on main — so the trim branch runs and
error.stack silently loses frames. The fix compares against the frame
count instead. The CHECK failure in the Node report comes from their
V8 14.6 backport, where kCount is 6 and the arithmetic is signed.

The new cctest fails on unpatched main and passes with the fix; the
targeted stack-trace tests and a UBSan build are clean.

One ask: I'm not a dry-runner, so CQ won't start a run for me — could a
committer kick off a dry run?

Reply all
Reply to author
Forward
0 new messages