Conversation
Collaborator
|
Review requested:
|
nodejs-github-bot
added
build
Collaborator
Collaborator
Collaborator
Collaborator
Member
|
Will this introduce the regression in #66074 to 24.x? |
Contributor
Author
Yes |
aduh95
marked this pull request as draft
September 23, 2026 14:06
aduh95
force-pushed
the
v24.x-staging
branch
from
September 25, 2026 16:48
d021bd6 to
13987f4
Compare
Original commit message:
[trace] Don't add 'new' to Wasm call site
When constructors builtins are inlined in Maglev, but the
constructor itself is not, we need to mark the call site
flag kIsConstructor. This allows the stack trace builder to add
the 'new' string.
However, this should not be done if the target is Wasm.
This creates the same stack trace string as Ignition.
Fixed: 450308355
Change-Id: I5c21eba3b46f97ddca9c51c21a66aa8169c0293c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7136920
Reviewed-by: Marja Hölttä <marja@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#103617}
Refs: v8/v8@853553f
Original commit message:
[objects]: Defer CallSiteInfo creation
Store the raw data in a FixedArray and create the CallSiteInfo objects
only on demand.
This can be further optimized to omit CallSiteInfo creation altogether
in some code paths, but currently those code paths are not critically important.
Change-Id: I6480862caf6b64020737527c571e3e3eac704ed3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7673818
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106127}
Refs: v8/v8@ebd1578
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#65764
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Original commit message:
[stack traces] Reduce stack frame summarization costs
During stack trace capture, Summarize() is the most expensive step — it
creates a full TranslatedState for every optimized frame even though
most frames are never inspected. This CL reduces that cost in two ways:
1. Lightweight Summarize() for optimized frames: instead of building a
full TranslatedState, walk only the deopt translation frame headers
and resolve function/receiver via ResolveTaggedValue(), falling back
to the full TranslatedState path for wasm-inlined or unresolvable
closures.
2. Deferred baseline frames: during CaptureSimpleStackTrace, baseline
frames store the raw Code + PC offset and defer bytecode offset
resolution to ExpandDeferredFrames(), which runs lazily before the
stack trace is formatted or inspected.
A new Torque bitfield flag (is_deferred_baseline_frame) marks entries in
the raw capture array that still need resolution. All consumers
(GetSimpleStackTrace, GetDetailedStackTraceFromCallSiteInfos,
GetFormattedStack, PrintCurrentStackTrace) call ExpandDeferredFrames()
before processing the array.
Change-Id: I1fe8cce918ba129d655d66f608ac6aa0ed160920
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7722138
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106237}
Refs: v8/v8@74e153d
Refs: v8/v8@c9c0abf
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#65764
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Original commit message:
[stack traces] Fall back to full walk when receiver is unboxed
The lightweight OptimizedJSFrame::Summarize path added in
crrev.com/c/7722138 assumed that closure and receiver are always
encoded as LITERAL or TAGGED_STACK_SLOT in the deopt translation.
This holds for the closure (a JSFunction reference is always tagged)
but not for the receiver: the "receiver" slot in an InterpretedFrame
translation is just parameter 0 of the (possibly inlined) frame and
is emitted via BuildDeoptFrameSingleValue, which encodes it according
to the value's representation. An inlined frame whose `this` was
typed as Float64 ends up as DOUBLE_STACK_SLOT, hitting UNREACHABLE in
ResolveTaggedValue.
Rename ResolveTaggedValue to TryResolveTaggedValue, return
std::optional, and fall back to SummarizeFull when the receiver isn't
a directly-resolvable tagged value.
Fixed: 499260582
Change-Id: I1f9cdd28e4b6b76a253a46e43b248d9239a4ecd8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7748309
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106423}
Refs: v8/v8@1a00890
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
PR-URL: nodejs#65764
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Original commit message:
[stack-traces] Fix overflow in Error.stackTraceLimit trimming
When stack traces are captured for uncaught exceptions (enabled via
Isolate::SetCaptureStackTraceForUncaughtExceptions, e.g. by the
inspector or by Node.js's --trace-uncaught), CaptureAndSetErrorStack
reuses the simple stack trace and trims it to Error.stackTraceLimit.
Error.stackTraceLimit counts frames, but the raw call site data stores
CallSiteInfo::Fields::kCount slots per frame, so the trim multiplied the
limit by kCount: once in the uint32_t comparison against the array
length and once, as int, to compute the new length. GetStackTraceLimit
clamps the limit to [0, INT_MAX], so for very large limits the uint32_t
product can wrap to a value below the array length. The trim branch is
then taken although the limit exceeds the number of captured frames,
and the int multiplication of the new length overflows.
On main (kCount == 5) the product first wraps at 858993460. That limit
trimmed the raw data to 4 slots (no complete frame) and 858993461 to 9
slots (one frame), so error.stack silently lost frames. Infinity, the
value from the Node.js report, is clamped to INT_MAX; its wrapped
product (2147483643) is not below the array length, so on main it does
not take the trim branch and does not reach the signed overflow.
Fix this by comparing the limit with the number of frames in the raw
data (length / kCount), and only multiplying once the limit is known to
be smaller than the frame count. The resulting length is then bounded
by the existing array length and cannot overflow. Behavior for limits
that did not overflow is unchanged, since the raw data length is always
a multiple of kCount.
This regressed with https://crrev.com/c/7673818 (ebd15783b7b,
"[objects]: Defer CallSiteInfo creation"), which switched from one
CallSiteInfo per frame to kCount raw slots per frame.
This is the underlying cause of Node.js issue 66074. The symptom there
differs from main: Node's V8 14.6 backport of that change has
kCount == 6 and uses int for the comparison and for RightTrim, so the
product overflows for limits above 357913941. For many of those,
including Infinity (INT_MAX * 6 wraps to -6), the result is negative
and fails "Check failed: new_capacity > 0." in RightTrim. Comparing in
frames avoids the overflow in both cases.
The new cctest CaptureStackTraceForUncaughtExceptionHugeStackTraceLimit
enables capture for uncaught exceptions and checks that limits of
858993460, 858993461 and Infinity yield the same error.stack as a limit
of 10, and that a limit of 1 still trims to a single frame. 858993460
and 858993461 are the first limits whose product with kCount wraps
around uint32_t; both fail without this change. The new test and the
existing stack trace tests also pass in a UBSan build, with no
diagnostics.
Bug: 565047704
Refs: nodejs#66074
Change-Id: I3422ca1de6a7dd9448c7fd53fb9bc5e40e2a17c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8426465
Reviewed-by: Patrick Thier <pthier@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: eliau elkouby (אליהו אלקובי) <eliau.elkouby@gmail.com>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110043}
Refs: v8/v8@786c1c2
Fixes: nodejs#66074
Assisted-by: a closed-source coding agent
Signed-off-by: Eliau Elkouby <145869377+eliau2005@users.noreply.github.com>
PR-URL: nodejs#66249
Reviewed-By: René <contact.9a5d6388@renegade334.me.uk>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
aduh95
force-pushed
the
backport-stack-frame-opti
branch
from
September 26, 2026 16:57
d1996b4 to
ea5c29c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of v8/v8@853553f + #65764 + #66249 to address #64879