- 20 Apr, 2022 1 commit
-
-
Simon Zünd authored
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/+/3596160Reviewed-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}
-
- 11 Apr, 2022 1 commit
-
-
Maksim Sadym authored
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/+/3472077Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Maksim Sadym <sadym@chromium.org> Cr-Commit-Position: refs/heads/main@{#79922}
-
- 08 Apr, 2022 1 commit
-
-
Benedikt Meurer authored
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}
-
- 06 Apr, 2022 1 commit
-
-
Benedikt Meurer authored
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/+/3571896Reviewed-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}
-
- 30 Mar, 2022 1 commit
-
-
Benedikt Meurer authored
This introduces a `V8InspectorClient::dispatchError()` callback that embedders can use to dispatch errors from scripts injected by DevTools (via debug evaluate). The idea here being that while these errors are technically caught by the inspector logic, the DevTools UX presents them just like other uncaught errors, with the exception that they don't trigger error handlers installed by the page. The latter can be quite confusing to developers, and surprising when for example testing these error handlers from DevTools. So this adds the foundations on the V8 side to enable triggering error handlers for these technically caught, but morally uncaught, exceptions. On the Chromium side https://crrev.com/c/3560458 will implement and use the hook. And that CL also adds a web tests to check the behavior. Bug: chromium:1295750 Change-Id: I945c8a9e9b4ec5705fc7f1891dcda185b04c8310 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3557234 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@{#79673}
-
- 04 Mar, 2022 2 commits
-
-
Benedikt Meurer authored
Previously, the inspector would resurrect `v8::internal::Script` objects when the weak callback is invoked, in order to access their fields and read out the source (either a String in case of JavaScript or the module bytes in case of WebAssembly). With https://crrev.com/c/3494242 we no longer need to access the `v8::internal::Script` now, and so we can stop relying on the `WeakCallbackType::kFinalizer` logic. Bug: chromium:1295659 Fixed: chromium:1302195 Doc: https://bit.ly/v8-inspector-script-caching Change-Id: I6a444bfcdf6cd23b30043f7386d6c18b7afec659 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497324Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#79366}
-
Benedikt Meurer authored
This introduces a new (inspector-only) `v8::debug::ScriptSource`, which represents the source for a given `v8::debug::Script` (in case of JavaScript it's a `v8::internal::String` while in case of WebAssembly it's a `Managed<v8::internal::wasm::NativeModule>`). Every `v8_inspector::V8DebuggerScript` now holds on weakly to the `v8::debug::Script` and strongly to its `ScriptSource`, making it possible to access the source even after the `Script` dies. This is preliminary work to allow for the removal of the special GC feature that a `WeakCallbackType::kFinalizer` callback can resurrect the object (this change is split into a separate follow up CL https://crrev.com/c/3497324). Bug: chromium:1295659, chromium:1302195 Doc: https://bit.ly/v8-inspector-script-caching Change-Id: I503d0d9283e2da392023f06f79b8ff35953e7935 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494242 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#79363}
-
- 01 Mar, 2022 1 commit
-
-
Benedikt Meurer authored
Don't expose the line end table logic to V8DebuggerScript, but instead use the existing Script::GetPositionInfo() logic to resolve end line and column numbers for scripts. This also avoids having to copy (the potentially huge) line ends tables to std::vector's twice per script. Bug: chromium:1162229 Change-Id: I03365d42c320d462360bacc444f7fa97904a9748 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494240 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#79311}
-
- 28 Feb, 2022 1 commit
-
-
Benedikt Meurer authored
This was originally introduced to address http://crbug.com/794941, to make the disassembly generation for WebAssembly modules lazy. Nowadays we no longer generate a text representation for the Wasm disassembly in V8, and this method always returns `false`. Bug: chromium:794941, chromium:1162229 Change-Id: I8b67e451a3657bf732615585577525aeea2b2f55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3494236 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#79304}
-
- 23 Feb, 2022 1 commit
-
-
Benedikt Meurer authored
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/+/3472082Reviewed-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}
-
- 22 Feb, 2022 3 commits
-
-
Benedikt Meurer authored
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}
-
Kim-Anh Tran authored
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/+/3477099Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#79203}
-
Simon Zünd authored
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/+/3477098Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#79199}
-
- 18 Feb, 2022 1 commit
-
-
Samuel Groß authored
Previously, V8_OS_MACOSX was, somewhat confusingly, also used for iOS. With this CL, V8_OS_DARWIN will be set on both macOS and iOS, V8_OS_MACOS only on macOS, and V8_OS_IOS only on iOS. This CL also renames V8_TARGET_OS_MACOSX to V8_TARGET_OS_MACOS and renames platform-xnu.cc to platform-darwin.cc. Change-Id: I4bcafc7c337586662114144f6c7ccf47d978da1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3468577Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#79167}
-
- 15 Feb, 2022 1 commit
-
-
Kim-Anh Tran authored
This CL adds the functionality to remove instrumentation breakpoints in wasm. Bug: chromium:1133307 Change-Id: I05ec7f8ac634267d95744ef4565d81cd0c372a2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460407Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#79088}
-
- 11 Feb, 2022 1 commit
-
-
Kim-Anh Tran authored
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/+/3442676Reviewed-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}
-
- 08 Feb, 2022 1 commit
-
-
Benedikt Meurer authored
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/+/3439865Reviewed-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}
-
- 07 Feb, 2022 1 commit
-
-
Benedikt Meurer authored
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}
-
- 04 Feb, 2022 2 commits
-
-
Alex Turner authored
This method returns the unique debugger ID for a v8::Context (i.e. the V8DebuggerID), serialized to a pair of int64_ts. Bug: v8:12528 Change-Id: Ib2cdda73447f8233f9afb773fed4a634d4618aef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369124Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Alex Turner <alexmt@chromium.org> Cr-Commit-Position: refs/heads/main@{#78958}
-
Clemens Backes authored
TimeTicks::HighResolutionNow is identical to TimeTicks::Now since 2018 (https://crrev.com/c/997153), but the declaration still has a wrong comment about a non-existing DCHECK. In order to avoid confusion, remove the redundant method and just use TimeTicks::Now everywhere. Drive-by: Make IsHighResolutionTimer "inline" instead of "V8_INLINE" because it will only be called once anyway. R=mlippautz@chromium.org Bug: v8:12425 Change-Id: I31dc65f8c1ac910862e070e60e928054d4921154 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439909Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#78944}
-
- 01 Feb, 2022 2 commits
-
-
Kim-Anh Tran authored
This explicitly passes along the break reason when requesting a pause that is handled via an interrupt. Pushing the break reason is not enough (as done before), as the reason may be used and consumed on another pause call that triggers a setPauseOnNextCall. Fixed: chromium:1292519 Change-Id: If8635c9397a7b9a1e6757be8048c9edc613c27f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3427208Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Auto-Submit: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78885}
-
Kim-Anh Tran authored
Bug: none Change-Id: I00903b3d709106b0aa6493bec916c70fa522b529 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429199 Auto-Submit: Kim-Anh Tran <kimanh@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/main@{#78882}
-
- 27 Jan, 2022 1 commit
-
-
Simon Zünd authored
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/+/3420304Reviewed-by: Kim-Anh Tran <kimanh@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#78809}
-
- 24 Jan, 2022 1 commit
-
-
Andrey Kosyakov authored
Change-Id: I4da78ec0f309c72007ee30336d77a77205f3e3fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406597 Auto-Submit: Andrey Kosyakov <caseq@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78729}
-
- 19 Jan, 2022 1 commit
-
-
Simon Zünd authored
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}
-
- 17 Jan, 2022 1 commit
-
-
Victor Porof authored
This CL exposes the `recurring` flag on the experimental async stack tagging API which was implemeted in the following CL: https://chromium-review.googlesource.com/c/v8/v8/+/3212506 It serves as a prototype to check if such an API is suitable for improving stack traces for frameworks which split up tasks across multiple frames, yielding back to the main thread when some time budget is consumed. The tests are implemented as Blink web tests in the following CL: https://chromium-review.googlesource.com/c/chromium/src/+/3383386 Bug: chromium:332624 Change-Id: I3e8c5de723cb7c0413d03ca4292c22d6a6e565b0 Signed-off-by: Victor Porof <victorporof@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380495Reviewed-by: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/main@{#78647}
-
- 13 Jan, 2022 2 commits
-
-
Lei Zhang authored
Use grep to check for obviously unneeded includes. e.g. headers that include <vector> but does not contain "std::vector". Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/main@{#78613}
-
Benedikt Meurer authored
This unifies and simplifies the way we instrument async functions for the purpose of async stack traces and async stepping. It does so while retaining the observable behavior on the inspector level (for now). Previously we'd mark the implicit promise of the async function object with the async task ID, and whenever we awaited, we'd copy the async task ID to the throwaway promise that is created by the `await`. This however made things unnecessarily interesting in the following regards: 1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the `AsyncFunctionFinished` events, coming from the throwaway promises, while the implicit promise is "done". This is especially confusing with rejection propagation and requires very complex stepping logic for async functions (after this CL it'll be possible to unify and simplify the stepping logic). 2. We have to thread through the "can suspend" information from the Parser all the way through AsyncFunctionReject/AsyncFunctionResolve to the async function instrumentation to decide whether to cancel the pending task when the async function finishes. This CL changes the instrumentation to only happen (non recurringly) for the throwaway promises allocated upon `await`. This solves both problems mentioned above, and works because upon the first `await` the stack captured for the throwaway promise will include the synchronous part as expected, while upon later `await`s the synchronous part will be empty and the asynchronous part will be the stack captured for the previous throwaway promise (and the V8Debugger automatically short circuits stacks with empty synchronous part). Bug: chromium:1280519, chromium:1277451, chromium:1246867 Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78599}
-
- 10 Jan, 2022 1 commit
-
-
Piotr Sikora authored
Signed-off-by: Piotr Sikora <piotrsikora@google.com> Change-Id: I776b98676df0094c141a395cfbe10801153e1076 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3343881Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78537}
-
- 05 Jan, 2022 2 commits
-
-
Benedikt Meurer authored
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}
-
Benedikt Meurer authored
This method performs exactly the same operation as the official `v8::Exception::GetStackTrace()`, which is already used in other places, so there's no point to have a duplicate of that in the debug interface. Bug: chromium:1283162 Change-Id: I09dd07f678165e1565bd77173e8ce64636ef649b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366659 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@{#78489}
-
- 04 Jan, 2022 2 commits
-
-
Benedikt Meurer authored
This change fixes the implementation of the previously introduced API `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply (consistently) to stack traces captured by V8 when exceptions are thrown. It does so in a fully backwards compatible manner. This change thus makes the previous fix for catapult (which landed in http://crrev.com/c/3347789) effective, and therefore ensures that real world performance benchmarks aren't affected by the use of the `Runtime` domain in the catapult test framework. Note this is basically a reland of crrev.com/c/3361839, but without touching the stack traces for console messages (which led to the regressions in crbug/1283516, crbug/1283523, etc.). Fixed: chromium:1280831 Bug: chromium:1283162, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Change-Id: I3dcec7b75d76ca267fac8bd6fcb2cda60d5e60dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364086Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78479}
-
Benedikt Meurer authored
This sprinkles some more trace events in the disabled by default "v8.inspector" category, to help with understanding performance impact of stack trace capturing better. Bug: chromium:1283162 Change-Id: I6085d587f241635fbb6934bef3adc95f58c5d2aa Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364085Reviewed-by: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78477}
-
- 03 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
This reverts commit 34f73cc7. Reason for revert: Performance regressions throughout a lot of system health and browsing benchmarks. Original change's description: > [inspector] Fix `Runtime.setMaxCallStackSizeToCapture`. > > This change fixes the implementation of the previously introduced API > `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply > (consistently) to stack traces captured by V8 when exceptions are > thrown. It does so in a fully backwards compatible manner. > > This change thus makes the previous fix for catapult (which landed in > http://crrev.com/c/3347789) effective, and therefore ensures that real > world performance benchmarks aren't affected by the use of the `Runtime` > domain in the catapult test framework. > > Bug: chromium:1283162, chromium:1278650, chromium:1258599 > Bug: chromium:1280803, chromium:1280832, chromium:1280818 > Fixed: chromium:1280831 > Doc: https://bit.ly/v8-cheaper-inspector-stack-traces > Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839 > 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@{#78458} Bug: chromium:1283162, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Bug: chromium:1280831 Change-Id: Id1efaffa2f7f08c47f833f68b8a297494edee21e Fixed: chromium:1283751, chromium:1283749, chromium:1283746 Fixed: chromium:1283729, chromium:1283700, chromium:1283700 Fixed: chromium:1283691, chromium:1283687, chromium:1283678 Fixed: chromium:1283677, chromium:1283676, chromium:1283675 Fixed: chromium:1283674, chromium:1283618, chromium:1283536 Fixed: chromium:1283523, chromium:1283516 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3364078 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78462}
-
- 31 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
This change fixes the implementation of the previously introduced API `Runtime.setMaxCallStackSizeToCapture` to work correctly and also apply (consistently) to stack traces captured by V8 when exceptions are thrown. It does so in a fully backwards compatible manner. This change thus makes the previous fix for catapult (which landed in http://crrev.com/c/3347789) effective, and therefore ensures that real world performance benchmarks aren't affected by the use of the `Runtime` domain in the catapult test framework. Bug: chromium:1283162, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Fixed: chromium:1280831 Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Change-Id: I4ec951a858317fa49096cd4023deb0104d92c9c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361839 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@{#78458}
-
- 30 Dec, 2021 2 commits
-
-
Benedikt Meurer authored
The `Console` domain has been deprecated (in favor of `Log` and `Runtime`) since over four years now, and its use is strongly discouraged. However, making `Runtime.setMaxCallStackSizeToCapture` useful (in light of the refactorings for crbug.com/1283162) and more correct (wrt. to the anticipated behavior), would be complicated seriously if we also need to worry about `Console` domain interference. So this CL simply removes the feature that `Console.enable` turns on stack trace capturing for error and message objects, and won't send `line`, `column`, and `url` with `Console.Message` events if they aren't present on the `v8_inspector::V8ConsoleMessage` instance (these fields have always been optional anyways). Bug: chromium:1283162 Change-Id: I78bd1e040fe15a2372639c403bfc2f4579fd4d0c Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3361837 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@{#78454}
-
Benedikt Meurer authored
This introduces a new `GetLocation()` method for `v8::StackFrame`s, which returns both line and column number at the same time (using the existing `v8::Location` class). Since `v8::StackFrame` instances store only the source position (per https://bit.ly/v8-stack-frame), we currently need to look up the source position in the Script's line table twice, once when we request the line number, and another time when we request the column number. With `GetLocation()` we perform only a single lookup in the Script's line table and return both line and column number at the same time. This cuts roughly 8% of the average execution time from the `standalone.js` benchmark mentioned in crbug.com/1280519. Bug: chromium:1280519, chromium:1278650, chromium:1069425 Bug: chromium:1077657, chromium:1283162 Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Change-Id: Ia3a0502990b6230363112a358b59875283399404 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359628Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78452}
-
- 14 Dec, 2021 1 commit
-
-
Aleksei Koziatinskii authored
Some embedders might want to process console.info and console.log differently. So inspector needs to return a different level for these console log messages. Change-Id: I936990a25f079a0d72f877a5095ed93819fc539a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3331929Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Alexey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/main@{#78357}
-
- 08 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
On the way to a cheaper and more scalable stack frame representation for the inspector (crbug/1258599), this removes the need to expose both what was called "function name" and what was called "function debug name" on a v8::StackFrame instance. The reason to having a distinction between that the V8 API exposes and what the inspector exposes as frame function name is that after the initial refactoring around v8::internal::StackFrameInfo, some wasm cctests would still dig into the implementation details and insist on seeing the "function name" rather than the "function debug name". This CL now addresses that detail in the wasm cctests and going forward unifies the function names used by the inspector and the V8 API (which is not only needed for internal consistency and reduced storage requirements in the future, but also because Blink for example uses v8 API and v8_inspector API interchangeably and assumes that they agree, even though at this point Blink luckily wasn't paying attention to the function name): - The so-called "detailed stack trace", which is produced for the inspector and exposed by the v8 API, always yields the "function debug name" (which for example in case of wasm will be a WAT compatible name), - while the so-called "simple stack trace", which is what is used to implement the CallSite API and underlies Error.stack continues to stick to the "function name" which in case of wasm is not WAT compatible). Bug: chromium:1258599 Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78283}
-
- 07 Dec, 2021 1 commit
-
-
Kim-Anh Tran authored
This removes the additional call to `didPause` solely for instrumentation breakpoints. They will be reported along with any other pause reasons, and if several apply, 'ambiguous' will be reported as a reason. Bug: chromium:1229541 Change-Id: I38557248dc2274c2ff2c396aa19073f4a5c5abd5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300134Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78271}
-