This CL fixes an issue with async stacks. The async task stack is not
torn down between page navigations or reloads. The result is that
any new async tasks are stacked on top of the old pages async task
stack.
This was not prominent until now for two reasons:
1) Async tasks created in blink are always finished as long as
destructors have time to run.
2) When V8 is terminated while running the micro task queue also
all async tasks created for Promises (including `await`) are
cleaned up properly.
Introducing the stack tagging API made it more common for having
unfinished async tasks open outside the MTQ, which left the
async task stack non-empty during navigation.
This CL fixes this problem by clearing out all the async task
and async stack data structures for a context group when that
context group is reset.
R=bmeurer@chromium.org, victorporof@chromium.org
Fixed: chromium:1328785
Change-Id: Iee0c3c4a55f66e643829dae3726dc03c735da1dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3666620
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80741}
This CL fixes a wrong assumption in the LiveEdit machinery. Namely
the assumption that every FunctionLiteral the parser finds, will have
a corresponding SFI created by the compiler. This assumption does not
hold in all cases. Inner functions that are never referenced by the
outer function don't get an SFI.
R=bmeurer@chromium.org
Fixed: chromium:1328453
Change-Id: I674f023f948954c1fcae04a4aa2afb69ea1642aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3663443
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80735}
Part of the improve error messages initiative.
Based on a resource of JSON.parse() errors found at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/JSON_bad_parse
Previously JSON.parse(NaN) would output:
SyntaxError: Unexpected token N in JSON at position 0
Now the output is:
SyntaxError: "NaN" is not valid JSON
Previously JSON.parse("{a:1}") would output:
SyntaxError: Unexpected token a in JSON at position 1
Now the output is:
SyntaxError: Expected property name or '}' in JSON at position 1
Bug: v8:6551
Change-Id: Ic9fad1fdbd295e1302805b81e6603fc526121960
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3513684
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Issack John <issackjohn@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#80567}
This is a reland of commit 8278cb5015
The reland adds the RestartFrameTrampoline to the list of
builtins that the deoptimizer is allowed to return from for
control flow integrity.
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: I13e2f8b5011795a38e541310622b8333a3d08049
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3644624
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80534}
This is more consistent with similar features, for example
V8_ENABLE_WEBASSEMBLY or V8_ENABLE_MAGLEV.
Drive-by: remove V8_SANDBOX_IS_AVAILABLE as it's no longer needed.
Bug: v8:10391
Change-Id: I8658c5b0c331a4c73892737083b2c2f9b8f84056
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647355
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80530}
This reverts commit 8278cb5015.
Reason for revert: breaking https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20CFI/10778/overview
Original change's description:
> [inspector] Re-enable Debugger#restartFrame
>
> Doc: https://bit.ly/revive-restart-frame
>
> This CL "undeprecates" Debugger#restartFrame and adds a new optional
> "mode" parameter for back-wards compatibility. Moreover, the return
> values are all deprecated. They were never actually used in the
> DevTools frontend and the same information is available from the
> Debugger#paused event that fires once execution stops at the
> beginning of the restarted function.
>
> The CL also re-baselines all the restart-frame inspector tests that
> now run successfully.
>
> R=bmeurer@chromium.org, kimanh@chromium.org
>
> Bug: chromium:1303521
> Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80491}
Bug: chromium:1303521
Change-Id: Ibc33328c31a4b6ea736d07ce5e5ee109039eec8b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3645767
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80495}
Doc: https://bit.ly/revive-restart-frame
This CL "undeprecates" Debugger#restartFrame and adds a new optional
"mode" parameter for back-wards compatibility. Moreover, the return
values are all deprecated. They were never actually used in the
DevTools frontend and the same information is available from the
Debugger#paused event that fires once execution stops at the
beginning of the restarted function.
The CL also re-baselines all the restart-frame inspector tests that
now run successfully.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I34bddeb1f2f4ff3dee58dd82e779c111495566f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616505
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80491}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
When formatting console messages (for consumption in Chromium/Blink), we
have special logic to unwrap value wrapper objects. But this logic was
not very consistent, and especially Number values and NumberObject
values were formatted differently.
This changes the V8ValueStringBuilder::append() logic to always unwrap
any value wrapper first and then use the regular dispatch for the
primitive value.
Fixed: chromium:1321833
Change-Id: I9996671e1f91da0841e5d5f1687cf647ab72a561
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622913
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80323}
This change adds support for computing SHA-256 hashes in the stack
output of errors by adding a function to the prototype of the
`CallSite` object, passed to `Error.prepareStackTrace`. Additionally,
it updates the `hash` property from `Debugger.scriptParsed` and
`Debugger.scriptFailedToParse` to be SHA-256 instead of the
proprietary hash it is today.
It is intended to be an advancement in indexing source maps to
support improved tooling, especially for post-hoc or in-production
diagnostics scenarios.
The explainer can be found here:
https://docs.google.com/document/d/13hNeeLC2Ve_FVieNndZUUUP15x2O4ltvjnGWwOsMlrU/edit?usp=sharing
Change-Id: Ifbbed4b22c8256e74e6d79974d2dd1e444143eda
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229957
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Auto-Submit: Robert Paveza <Rob.Paveza@microsoft.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80320}
We weren't really translating between location (line and column number)
and source position (character offset) consistently, especially when it
came to inline <script>s. There were also inconsistencies between what
Debugger.getPossibleBreakpoints and Debugger.setBreakpointByUrl would
do.
With this CL, we are now consistently operating under the following
assumptions:
(1) For inline <scripts>s with a //@ sourceURL annotation, we assume
that the line and column number that comes in via the protocol is
in terms of the source text of the script.
(2) For inline <script>s without said annotation, we assume that the
line and column numbers are in terms of the surrounding document.
This is finally aligned with how the DevTools front-end operates.
Fixed: chromium:1319828
Change-Id: I98c4ef04b34a97caf060ff4f32690b135edb6ee6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610622
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80292}
If the debug handler (called via {OnDebugBreak}) requests termination of
the isolate, this would only get considered on the next stack check,
where it is turned into a proper termination exception.
Handling this correctly is further complicated by the {DebugScope}
blocking any handling of interrupts via the included
{PostponeInterruptsScope}.
Hence this CL refactors the code to call any debug handlers in a second
function which has the {DebugScope}, and to check for interrupts after
leaving that scope.
R=thibaudm@chromium.orgCC=bmeurer@chromium.org
Bug: chromium:1319343
Change-Id: Ia2df0f2610d50eedc6437841c4bf1d2ad3ac9125
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605228
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80235}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds a new optional flag `canBeRestarted` to every call frame
in Debugger.paused events. As the name suggests, the flag indicates
whether we can restart a particular frame through Debugger.restartFrame
once implemented.
We are not able to safely restart all frames:
* We don't support WASM frames
* We don't support frames where resumable functions (async fns,
generators) and embedder C++ frames are between the top-most
frame and the to-be-restarted frame.
Note that from a CDP perspective the flag doesn't actually guarantee
a successful restart. CDP clients can issue
CDP commands between the Debugger.paused event and before a user
decides to restart a frame, which can potentially mess
with the stack.
The `canBeRestarted` flag tests are folded into the
Debugger.restartFrame tests. As the feature is not yet fully
implemented we short-circuit most of the tests for now and only
run them up until the first Debugger.restartFrame call fails
(except "fails-for-resumables.js").
This means the tests exercise the `canBeRestarted` flag, but not
the restarting functionality itself.
R=bmeurer@chromium.org, kimanh@chromium.org
Bug: chromium:1303521
Change-Id: I01ab46dc3557ab8383960969fbe03e00604cc5e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596160
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80046}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds the second batch of inspector tests for the upcoming
"Restart frame" feature. Landing the tests upfront allows us to
better discuss the proposed API as well as think early about
corner cases we should test.
The tests check for the functionality of `Debugger.restartFrame`, as
well as the newly added parameter `canBeRestarted` in
the `Debugger.paused` event.
Bug: chromium:1303521
Change-Id: Ie9dda100cdc5217a4e4cc2f0cf7019a33d124120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585947
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80037}
Doc: https://bit.ly/revive-restart-frame
Context: https://crrev.com/c/3582395 (whole feature)
This CL adds the first batch of inspector tests for the upcoming
"Restart frame" feature. Landing the tests upfront allows us to
better discuss the proposed API as well as think early about
corner cases we should test.
The tests check for the functionality of `Debugger.restartFrame`, as
well as the newly added parameter `canBeRestarted` in
the `Debugger.paused` event.
Bug: chromium:1303521
Change-Id: Ibda6d8b6110fce893e0844f8902fbd5d901ae01d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585946
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80013}
1. Added `generateWebDriverValue` flag to `Runtime.evaluate` and `Runtime.callFunctionOn`.
2. Added `webDriverValue` field to `RemoteObject`, and set it in case of the `generateWebDriverValue` flag was set.
3. Added virtual method `bidiSerialize` to allow embedder-implemented serialization (like in https://crrev.com/c/3472491).
4. Implemented V8 serialization in a separate class `V8WebDriverSerializer`.
5. Hardcode `max_depth=1`.
6. Added tests.
Not implemented yet:
1. `objectId`.
2. Test of embedder-implemented serialization.
Tested automatically by:
```
python3 tools/run-tests.py --outdir out/foo inspector/runtime/add-web-driver-value
```
Naming to be discussed. Suggestions are very welcome.
Design doc: http://go/bidi-serialization
Change-Id: Ib35ed8ff58e40b3304423cc2139050136d844e2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472077
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Maksim Sadym <sadym@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79922}
For large BigInts, computing the decimal representation can take a
very long time, so send them as hexadecimal strings instead. Also
make sure to abbreviate the RemoteObject description for bigints
appropriately always.
Also-By: jarin@chromium.org
Fixed: chromium:1068663
Change-Id: I2f7e4e1cbd2f66ce45be307fb787e101d9a8e2a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578653
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79872}
Since the inspector does not longer hold on strongly to Script objects
after they were collected by V8, this test was relying on the GC to not
collect the scripts too eagerly in case where nothing else holds on to
the script. So explicitly adding a global object property assignment
here in those cases to ensure that the Script is kept alive.
Fixed: chromium:1314212, v8:12699
Bug: chromium:1246884, chromium:1295659
Change-Id: Ia16fcf841aeb29bf131fc6fa066f120d342f94b2
Doc: https://bit.ly/v8-inspector-script-caching
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576117
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79852}
Similar to what we did for FunctionMirror before in
https://crrev.com/c/2887508, we also need to avoid running user
JavaScript for DateMirrors.
This also refactors the ToDateString logic a bit.
Fixed: chromium:1311613
Change-Id: I793b86106765550a9aa449f85f0766840081cc58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571896
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79821}
Reporting messages can trigger termination in case of `inspector-test`,
which we need to be able to deal with gracefully for the fuzzer.
Fixed: chromium:1307449
Change-Id: I88ba2b13d920134a1670b808adc4ace4ca6d1dff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540260
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79543}
Maglev is mid-tier optimising compiler designed mainly for compilation
speed that can still generate good code for straightforward JS.
This initial commit is an MVP for Maglev which can compile and run some
very simple code, and sets up a framework that we can build upon.
Design:
https://docs.google.com/document/d/13CwgSL4yawxuYg3iNlM-4ZPCB8RgJya6b8H_E2F-Aek/edit#
Bug: v8:7700
Change-Id: I5ae074ae099126c2c0d50864ac9b3d6fa5c9e85a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483664
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79247}
When triggering a step out action, we check whether we already
are at a return or suspend location. If not, we first flood all
return positions with breakpoints, set the fast_forward_to_return_
flag and continue.
With the new way of reporting instrumentation breakpoints, we now
may get into the situation where we stopped on an instrumentation,
but may still need to continue until we reach the return point for
the step out. This CL fixes a bug in which we ran into a DCHECK
that expected us to stop on a return location (since
fast_forward_to_return_ is set to true), but we didn't.
Drive-by: adapt other stepping tests to properly wait for all pauses
Bug: chromium:1229541
Change-Id: Ie5fd358922f4cdaf1f8584bb0b35e87b0e221fb8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3480094
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79226}
Previously we'd hold on to Script objects strongly after they are
considered unreachable by V8 itself, and keep them around for the
V8DebuggerAgent cache (whose upper limit can be controlled with a
parameter to `Debugger.enable`).
This CL changes that to instead copy out the script source and the
WebAssembly bytecode (depending on whether it's JavaScript or Wasm)
to the C++ heap and keep it cached there.
Fixed: chromium:1295659
Bug: chromium:1246884
Change-Id: Idfcd7172715eafca6b011826ae03a573d58803f2
Doc: https://bit.ly/v8-inspector-script-caching
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472082
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79217}
When calling `Runtime.getProperties` with `accessorPropertiesOnly` we
previously did not report any private fields at all, although it is
possible to define private accessors.
Bug: chromium:1296855
Change-Id: I18b84bfc81449d224738ba3de1f0c41c234025b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477112
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79210}
Calling didContinue() after having paused on an instrumentation break
clears the breakpoint reasons that were stored in the debugger agent.
This removes clearBreakDetails() from didContinue() and specifically
calls it if we need it.
Drive-by: removing left-over dead code
Bug: chromium:1229541
Change-Id: I49f598d0e97801661e003c3911967c64ea63373e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477099
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79203}
The ExceptionDetails structure allows the association of requests and
issues with JavaScript errors. These are currently only reported
when an exception goes through `Runtime#exceptionThrown`, but we
also want the metadata available when the ExceptionDetails are
requested explicitly for any Error object.
R=bmeurer@chromium.org
Bug: chromium:1280141
Change-Id: I1b1514207b9e146fda3452c3f7991cd7dc9a387b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477098
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79199}
This changes the way how we are handling instrumentation breakpoints.
Motivation:
with instrumentation breakpoints, we need a way to break
on (conditional) breakpoints that were just set by the client on
the instrumentation pause.
How:
We want to first find out if we have an instrumentation break, and
trigger a pause. For this to work, we need to distinguish between
regular and instrumentation breakpoints in the debugger back-end.
On resume, we want to check if we have hit any breakpoints (may
now contain new breakpoints due to the client setting new breakpoints
at the previous instrumentation pause) and trigger a separate pause
for them.
Fixed: chromium:1292930
Change-Id: Idaadd276c44c693f856c4b08c7a72ea67271f420
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3442676
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79053}
Handle the case of nested super() by checking if the class scope
contains a private brand. In this case the ContextScope chain
is different from the actual context chain so this added back
the AddPrivateBrand() runtime function but with the additional
step of walking the context chain to get the correct class
context that will be stored as the value of the brand property
for the debugger.
Bug: v8:12354
Change-Id: Ieeb9b9d6372bfbb1a39c4c2dc9e9848e9109f02a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275137
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79032}
Not all environments (like ShadowRealm) would expect console
APIs to present in their globals. Moving console API to
context's extras binding to allow them to be still
snapshotted to not slow down the bootstrap.
The console API is not removed from the global in this CL,
but it is planned to be removed in the later release.
Bug: v8:11989
Change-Id: Ieca09e0bafdf8943e8fff8fee97fc21c2326320f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364786
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Chengzhong Wu <legendecas@gmail.com>
Cr-Commit-Position: refs/heads/main@{#78998}
Previously the inspector was trying to handle step-out for async
functions by annotating the async stacks, but this was merely a
hack and didn't work reliably
(a) when the async caller that is `await`ing the result of the
callee was still in the synchronous part (because then there
was no async task yet in the inspector), or
(b) not at all when the async stack tracking wasn't enabled or the
maximum async stack depth was too small.
This CL replaces that hack with a pragmatic solution inside the
V8 debugger, where upon `await` we memorize the async function
object of the caller on the outer promise of the callee, and when
stepping out of the callee we check whether the returned promise
has a memorized async function object and if so, we schedule that
to resume.
This CL thereby effectively reverts https://crrev.com/c/1054618
and replaces it with a V8 debug solution, and thereby further
reduces the (memory) overhead of an AsyncStackTrace.
Fixed: chromium:1246867
Bug: v8:6161, v8:7753, chromium:1277451, chromium:1280519
Change-Id: I6aa79e90f49d204f66bfd37e7a328c7fb8d635b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439865
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78990}
Properly push back the current request promise for async generators when
resuming after an `await` to ensure that the catch prediction works as
expected for async generators.
Fixed: chromium:1220203
Change-Id: I8c3592ceb567aadcba8f460794cd5d60a965a360
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3442680
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78984}
This is the final step towards moving away from sending `url` with
every call frame when emitting the `Debugger.paused` event.
Fixed: chromium:1270316
Bug: chromium:1271078
Change-Id: I87a286d81eb91a9bed64213c4b18db0675858822
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3345001
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78974}
This is the second step towards moving away from sending `url` with
every call frame when emitting the `Debugger.paused` event.
Bug: chromium:1270316, chromium:1271078
Change-Id: Ib4f996024b5200cded155bd8a564d01d36856400
Doc: https://bit.ly/devtools-debugger-callframe-url
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431485
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78906}
Previously we'd predict exceptions thrown in [[Reject]] handlers as
always caught (by PromiseRejectReactionJob), but that's not what is
actually specified in ECMAScript. The PromiseRejectReactionJob will turn
any exception thrown into a promise rejection just like we do in the
case of PromiseFulfillReactionJob, and so the catch prediction should
match that behavior.
Fixed: chromium:1290861
Change-Id: Id992708b009666da7c6bf1b6e3cf30752ca0a227
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3423775
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78864}
This CL replaces the equirecursive type system for wasm-gc with the
isorecursive hybrid type system presented here:
https://github.com/WebAssembly/gc/issues/257.
In broad strokes, this includes the following changes:
- In the module decoder, remove equirecursive types. Implement recursive
type groups, subtype definitions, and function/struct/array
definitions. Treat nominal modules as syntactic sugar of an
isorecursive module, where all types belong in the same recursive
group.
- Remove rtt.sub and all related infrastructure.
- Change subtyping to work with explicit supertypes only.
- Add ValidSubtypeDefinition in subtyping, to check that subtype
declarations are valid during decoding.
- Remove the subtyping cache.
- Add support for functions to have specific signature index in
WasmModuleBuilder and in test-gc.cc.
- Adapt tests.
Current restrictions:
- Recursive groups are not stored beyond decoding.
- Type canonicalization is not implemented. No tests relying on types
being considered identical post-canonicalization.
- No cross-module subtyping is possible. Tests relying on cross-module
subtyping have been commented out.
Bug: v8:7748
Change-Id: I69fd04ecc5611f6230c95d5c89d1c520163fffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416239
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78816}
This CL replaces 'InvalidArgument' with 'ServerError' for
Runtime#getExceptionDetails. The reason is that the error we
raise is on the application level, allowing the DevTools frontend
to handle it to a certain degree. 'InvalidArgument' errors would be
interpreted as "something went really wrong", which is not the case
here.
Bug: chromium:1280141
Change-Id: Id72f06ce8daa06875adeb2528638a80ae61d9e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420304
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78809}
This is a reland of 91f08378bc
When the class scope does not need a context, the deserialized
outer scope of the initializer scope would not be the class scope,
and we should not and do not need to use it to fix up the allocation
information of the context-allocated variables. The original patch
did not consider this case and resulted in a regression when we
tried to reparse the initializer function to look for destructuring
assignment errors. This fixes the regression by not deserializing
the class scope that's going to be reparsed, and using the positions
of the scopes to tell whether the scope info matches the reparsed
scope and can be used to fix up the allocation info.
Original change's description:
> [class] implement reparsing of class instance member initializers
>
> Previously, since the source code for the synthetic class instance
> member initializer function was recorded as the span from the first
> initializer to the last initializer, there was no way to reparse the
> class and recompile the initializer function. It was working for
> most use cases because the code for the initializer function was
> generated eagarly and it was usually alive as long as the class was
> alive, so the initializer wouldn't normally be lazily parsed. This
> didn't work, however, when the class was snapshotted with
> v8::SnapshotCreator::FunctionCodeHandling::kClear,
> becuase then we needed to recompile the initializer when the class
> was instantiated. This patch implements the reparsing so that
> these classes can work with FunctionCodeHandling::kClear.
>
> This patch refactors ParserBase::ParseClassLiteral() so that we can
> reuse it for both parsing the class body normally and reparsing it
> to collect initializers. When reparsing the synthetic initializer
> function, we rewind the scanner to the beginning of the class, and
> parse the class body to collect the initializers. During the
> reparsing, field initializers are parsed with the full parser while
> methods of the class are pre-parsed.
>
> A few notable changes:
>
> - Extended the source range of the initializer function to cover the
> entire class so that we can rewind the scanner to parse the class
> body to collect initializers (previously, it starts from the first
> field initializer and ends at the last initializer). This resulted
> some expectation changes in the debugger tests, though the
> initializers remain debuggable.
> - A temporary ClassScope is created during reparsing. After the class
> is reparsed, we use the information from the ScopeInfo to update
> the allocated indices of the variables in the ClassScope.
>
> Bug: v8:10704
> Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#78299}
Bug: chromium:1278086, chromium:1278085, v8:10704
Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#78745}
This is a regression test for the fixes in
https://crrev.com/c/v8/v8/+/3299592 . Some of the helper functions were
copied from console-retaining-path.js in the same directory.
Bug: v8:12112
Change-Id: I3c313ad003ede5e5036f886161e1d164c98f87fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400149
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#78689}
CDP has a "ExceptionDetails" structure that is attached to various
CDP commands, e.g. "Runtime#exceptionThrown" or "Runtime#evaluate".
The stack trace in the "ExceptionDetails" structure is used in
various places in DevTools. The information in the "ExceptionDetails"
structure is extracted from a v8::Message object. Message objects
are normally created at the exception throw site and may augment
the error with manually inspecting the stack (both to capture a fresh
stack trace in some cases, as well as to calculate location info).
The problem is that in some cases we want to get an "ExceptionDetails"
structure after the fact, e.g. when logging a JS "Error" object in
a catch block. To help in this case, this CL introduces a new
CDP method "Runtime#getExceptionDetails" that behaves exactly as
advertised: It provides a populated "ExceptionDetails" structure
from a JS Error object.
R=bmeurer@chromium.org
Doc: https://bit.ly/runtime-get-exception-details
Bug: chromium:1278650
Change-Id: I084be10c1d852d3b7cac8d88e7f820e867be4722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3337258
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78676}
When creating a new JSError object (or using the non-standard API
`Error.captureStackTrace`) V8 would previously capture the "simple stack
trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
standard `error.stack` property, and if the inspector was active also
capture the "detailed stack trace" (as FixedArray of StackFrameInfo
instances). This turns out to be quite a lot of overhead, both in terms
of execution time as well as memory pressure, especially since the
information needed for the inspector is a proper subset of the
information needed by `error.stack`.
So this CL addresses the above issue by capturing only the "simple stack
trace" (in the common case) and computing the "detailed stack trace"
from the "simple stack trace" when on demand. This is accomplished by
introducing a new ErrorStackData container that is used to store the
stack trace information on JSErrors when the inspector is active. When
capturing stack trace for a JSError object while the inspector is
active, we take the maximum of the program controlled stack trace limit
and the inspector requested stack trace limit, and memorize the program
controlled stack trace limit for later formatting (to ensure that the
presence of the inspector is not observable by the program).
On the `standalone.js` benchmark from crbug.com/1283162 (with the
default max call stack size of 200) we reduce execution time by around
16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
regression in crbug.com/1280831), we are 6% faster now.
Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
Bug: chromium:1280831, chromium:1278650, chromium:1258599
Bug: chromium:1280803, chromium:1280832, chromium:1280818
Fixed: chromium:1283162
Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78542}
The V8InspectorSessionImpl constructor accepts a state, as either text
or CBOR encoded, and generally ignores all invalid inputs, except for
the case where it's a valid value, but not a dictionary value, in which
case it'll leak the value and crash upon casting to a `DictionaryValue`.
This is purely an issue with the test driver, so no security impact on
Chromium in the wild.
Fixed: chromium:1281031
Change-Id: I7b4d0aea83370499b1274d3fa214a14dc098d2f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361838
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78490}
