- 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 1 commit
-
-
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}
-
- 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}
-
- 02 Dec, 2021 1 commit
-
-
Kim-Anh Tran authored
This CL makes sure to forward the information that we are pausing because of a debugger statement, and to encode it explicitly as an 'other' reason when reporting the pause to the front-end. Drive-by: refactoring the way break reasons are propagated by introducing a new enum for break reasons Bug: chromium:1229541, chromium:1133307 Change-Id: I9d2e8d8da54d96a231eff9d1f62b74507955b18f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3306978Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78202}
-
- 29 Nov, 2021 1 commit
-
-
Kim-Anh Tran authored
Previously, we would encode 'other' as a reason for pausing when stepping too, however, it would not show as such in case it would overlap with another reason. This CL makes sure that we always report 'other' as a reason if we are stepping. Drive-by: only encode 'other' as a reason once Bug: chromium:1229541 Change-Id: Id73822dff68d1d54a2f1fafdf2a097e1377ece75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295346Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/main@{#78118}
-
- 27 May, 2021 1 commit
-
-
Scott Violet authored
When 'beforeScriptExecution' is enabled, a pause event may be generated with a reason of 'instrumentation' rather than 'other.' This patch ensures that in the case of a schedule-break, both an 'instrumentation' and 'other' pause event is generated. This is important for debuggers that rely on getting 'other' breakpoints to determine if they should actually break, or continue executation. Change-Id: I73613f4df6fa7942e7ca2be58853e5420589ba0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2915680Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#74827}
-
- 28 Dec, 2020 1 commit
-
-
Benedikt Meurer authored
With https://crrev.com/c/2087396 we introduced a new CDP method `Debugger.executeWasmEvaluator()`, which we originally intended to use as the foundation for Debug-Evaluate on Wasm frames. However in the process of prototyping we learned that it is too costly and too inefficient to use WebAssembly modules here, and we switched to regular Debug-Evaluate with JavaScript instead (with a special debug proxy exposed that allows JavaScript to peak into the Wasm frame), since JavaScript is better suited for short-lived / short-running snippets and we don't need clang and wasm-ld then to generate these snippets. The JavaScript exposed debug proxy (as described in [1]) not only enables more powerful and flexible Debug-Evaluate for the DWARF C/C++ extension, but also serves as the basis for various aspects of the Basic Wasm Developer Experience. In order to pay down technical debt and to keep the maintenance overhead low, we should remove the initial prototype now, also to ensure that we don't accidentally attract other users of CDP to rely on this unsupported API (despite it being marked as "experimental"). [1]: https://docs.google.com/document/d/1VZOJrU2VsqOZe3IUzbwQWQQSZwgGySsm5119Ust1gUA Fixed: chromium:1162062 Bug: chromium:1020120, chromium:1068571, chromium:1127914 Change-Id: I6dba8c906a8675ce6c29a52e3c32bb6626a27247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605186 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#71882}
-
- 18 Nov, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I71fabf7628ec13440585c24381f5ba89e4df03d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543168Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#71246}
-
- 11 Aug, 2020 1 commit
-
-
Kim-Anh Tran authored
This change adds support for skipping locations that are in a skipList on step over. This feature is useful for when we are debugging C++ applications that have DWARF information we only want to stop on every breakable location in C++, not non every breakable location on wasm level. Bug: chromium:1105765 Change-Id: Ie835b011a00cf31e0c5b2df1ac96ebd89f53d23a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339458Reviewed-by: Eric Leese <leese@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#69329}
-
- 04 Aug, 2020 1 commit
-
-
Kim-Anh Tran authored
This adds CDP methods to support skipping locations on stepOver and stepInto. Bug: chromium:1105765 Change-Id: I8b902009883807082cf5fda0411b992e90dee81d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2335181Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#69223}
-
- 05 May, 2020 1 commit
-
-
Philip Pfaffe authored
Allow the DevTools frontend to evaluate variables in a wasm frame context by reusing the existing Debugger expression evaluation API. Where previously the API expected JavaScript expressions, which would in general just fail, now the expression is expected to be base64 encoded Wasm that creates a JSON string in linear memory. Bug: chromium:1020120 chromium:1068571 Change-Id: I4b31fdb9d3b21b4e08c4995ec2f07880923959e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087396Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Philip Pfaffe <pfaffe@chromium.org> Cr-Commit-Position: refs/heads/master@{#67568}
-
- 03 Feb, 2020 1 commit
-
-
Sigurd Schneider authored
This CL implements functionality to allow an embedder to mark a debug scope as terminate-on-resume. This results in a termination exception when that debug scope is left and execution is resumed. Execution of JavaScript remains possible after a debug scope is marked as terminate-on-resume (but before execution of the paused code resumes). This is used by blink to correctly prevent resuming JavaScript execution upon reload while being paused at a breakpoint. This is important for handling reloads while paused at a breakpoint in blink. The resume command terminates blink's nested message loop that is used while to keep the frame responsive while the debugger is paused. But if a reload is triggered while execution is paused on a breakpoint, but before execution is actually resumed from the breakpoint (that means before returning into the V8 JavaScript frames that are paused on the stack below the C++ frames that belong to the nested message loop), we re-enter V8 to do tear-down actions of the old frame. In this case Runtime.terminateExecution() cannot be used before Debugger.resume(), because the tear-down actions that re-enter V8 would trigger the termination exception and crash the browser (because the browser expected the tear-down to succeed). Hence we introduce this flag on V8 that says: It is OK if someone re-enters V8 (to execute JS), but upon resuming from the breakpoint (i.e. returning to the paused frames that are on the stack below), generate a termination exception. We deliberated adding a corresponding logic on the blink side (instead of V8) but we think this is the simplest solution. More details in the design doc: https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk Bug: chromium:1004038, chromium:1014415 Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#66084}
-
- 18 Dec, 2019 1 commit
-
-
Z Nguyen-Huu authored
In setting breakpoint in wasm, we can find wasm script from location but in removing a breakpoint, only breakpoint id is provided. For wasm, we have a list of all BreakPointInfo objects attached to the Script. From breakpoint id, we iterates all scripts to find the targeted breakpoint and remove it. Bug: chromium:837572 Change-Id: Ia5d0fb7d804fb98270b2103232bc10eb5d4f93a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1959749 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#65505}
-
- 15 Nov, 2019 1 commit
-
-
Eric Leese authored
Currently the inspector reports Wasm in one of two ways: - If there is a source map, report one script per Wasm script, with bytecode but no source. - If there is no source map, report one script per Wasm function, with source (Wasm disassembly) but no bytecode. With this change, behavior with source map is same, but without source map it will report both ways. This will allow us to change the frontend to do its own disassembly, allowing us to remove the per-function scripts in a future change. Bug: chromium:1013527 Change-Id: I0c559ad08896e8d0da419e3c6ad8d1edff3976fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1899782Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Eric Leese <leese@chromium.org> Cr-Commit-Position: refs/heads/master@{#64980}
-
- 08 Oct, 2019 1 commit
-
-
Ingvar Stepanyan authored
Unfortunately, codebase contains lots of places that use one of the two formats as an internal representation for Wasm locations: 1) {line: 0, column: byte offset within entire module} 2) {line: function index, column: byte offset within function} These places choose these formats interchangeably and convert from one to another depending on the presence of source map URL in Wasm. This is not very convenient and makes it hard to add support for DWARF which should behave just like Wasm with source maps - that is, report a raw Wasm script instead of fake scripts per each disassembled function, and use representation (1) instead of (2) internally. I tried to refactor these locations and avoid checking for source map URLs in the previous CL - https://crrev.com/c/v8/v8/+/1833688. However, it quickly got out of hand, and updating code in one place just kept revealing yet another that gets broken by the changes, so I made a decision to abandon it and leave to someone who knows the codebase better. Instead, this CL is based on https://crrev.com/c/v8/v8/+/1809375, but, rather than trying to integrate DWARF separately and only for supported agents, it pretends that encountering DWARF section is the same as encountering a `sourceMappingURL` section with fake URL "wasm://dwarf". This ensures that Wasm with DWARF behaves exactly in the same way as Wasm with source maps, just like we want, with minimal changes to the codebase. The only downside is that frontends without DWARF support won't get even a disassembled version of Wasm that contains DWARF info. This is unfortunate, but, as per previous discussions, should be fine given current state of Wasm debugging. Change-Id: Ia7256075e4bfd2f407d001d02b96883d7267436e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834341 Commit-Queue: Ingvar Stepanyan <rreverser@google.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64157}
-
- 25 Sep, 2019 1 commit
-
-
Ingvar Stepanyan authored
This addition will allow to experiment with parsing DWARF information from WebAssembly on the frontend side for improved debugging. The frontend must explicitly opt-in to this experiment by setting `supportsWasmDwarf: true` in `Debugger.enable` params. When this option is present, and Wasm appears to contain DWARF information (heuristic: `.debug_info` custom section is present), V8 will not try to disassemble and report each WebAssembly function as a separate fake script, but instead will report Wasm module as a whole. Note that V8 already does this when Wasm is associated with a source map. Additionally, this CL adds a dedicated `Debugger.getWasmBytecode` command that accepts scriptId and returns raw wire bytes of the chosen WebAssembly module. Change-Id: I7a6e80daf8d91ffaaba04fa15688f2ba9552870f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1809375 Commit-Queue: Ingvar Stepanyan <rreverser@google.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63969}
-
- 13 Sep, 2019 2 commits
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
Dmitry Gozman authored
Currently, debugger pauses on async call schedule and then waits for Debugger.pauseOnAsyncCall with parentStackTraceId to actually schedule the pause. This CL combines these two steps: - For local async tasks, it just stores m_taskWithScheduledBreak at the time of schedule, to be able to pause once this task is run. - For external async tasks, it plumbs "should_pause" boolean in V8StackTraceId from the point of schedule to the point of execution, and schedules a pause once externalAsyncTaskStarted is called with "should_pause" set to true. This approach greatly simplifies the implementation, and reduced frontend to a single "breakOnAsyncCall: true" parameter in Debugger.stepInto. Drive-by: introduce hasScheduledBreakOnNextFunctionCall() to make SetBreakOnNextFunctionCall management more robust. Note: artificial pauses at async call schedule time are gone from test expectations - we now only pause when user actually wants to pause, which makes protocol much simpler. See also design doc linked in the bug. BUG=chromium:1000475 Change-Id: I2d16f79c599fe196b2aaeca8223c63437a2954a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783724 Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#63737}
-
- 08 May, 2019 1 commit
-
-
Aleksei Koziatinskii authored
There are two possible type: - scriptParsed - breakpoint for any script, - scriptWithSourceMapParsed - breakpoint for script with sourceMappingURL. When one of the breakpoints is set then for each matched script we add breakpoint on call to top level function of that script. Node: https://github.com/nodejs/node/issues/24687 R=dgozman@chromium.org Bug: chromium:887384,chromium:724793,chromium:882909 Change-Id: I9c08b2a2a5ba7006adfedd85fc92ae191517af00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1354245Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#61353}
-
- 16 Mar, 2019 1 commit
-
-
Alexei Filippov authored
This is a reland of 5a61630d Original change's description: > [inspector] Allow limiting the total size of collected scripts. > > Introduces the setMaxCollectedScriptsSize Debugger protocol method. > If the max size is set, the debugger will hold collected (not referenced by other v8 heap objects) > scripts up to the specified total size of their sources. > > BUG=v8:8988 > > Change-Id: I94d52866494102add91ca2d569a2044b08c9c593 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518556 > Commit-Queue: Alexei Filippov <alph@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60227} TBR=dgozman@chromium.org Bug: v8:8988 Change-Id: I9b1db01856a43636c1eb8ad2ec36e3727353228d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524668 Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Cr-Commit-Position: refs/heads/master@{#60271}
-
- 15 Mar, 2019 2 commits
-
-
Maya Lekova authored
This reverts commit ba00d8b7. Reason for revert: Breaks arm64 bots (native & simulator) - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/17252 Original change's description: > Reland: [inspector] Allow limiting the total size of collected scripts. > > Introduces the setMaxCollectedScriptsSize Debugger protocol method. > If the max size is set, the debugger will hold collected (not referenced by other v8 heap objects) > scripts up to the specified total size of their sources. > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518556 > > Commit-Queue: Alexei Filippov <alph@chromium.org> > > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > > BUG=v8:8988 > TBR=dgozman@chromium.org > > Change-Id: I6f7da07c4c9ae35b5252aabddb98b693ec77b4e8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524662 > Reviewed-by: Alexei Filippov <alph@chromium.org> > Commit-Queue: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60255} TBR=dgozman@chromium.org,alph@chromium.org Change-Id: I04e3616d46620f33d0ec349fb7b0c393f276dc0c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8988 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524484Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#60257}
-
Alexei Filippov authored
Introduces the setMaxCollectedScriptsSize Debugger protocol method. If the max size is set, the debugger will hold collected (not referenced by other v8 heap objects) scripts up to the specified total size of their sources. > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518556 > Commit-Queue: Alexei Filippov <alph@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> BUG=v8:8988 TBR=dgozman@chromium.org Change-Id: I6f7da07c4c9ae35b5252aabddb98b693ec77b4e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524662Reviewed-by: Alexei Filippov <alph@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#60255}
-
- 14 Mar, 2019 2 commits
-
-
Maya Lekova authored
This reverts commit 5a61630d. Reason for revert: Breaking gc stress bot - https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/21477 Original change's description: > [inspector] Allow limiting the total size of collected scripts. > > Introduces the setMaxCollectedScriptsSize Debugger protocol method. > If the max size is set, the debugger will hold collected (not referenced by other v8 heap objects) > scripts up to the specified total size of their sources. > > BUG=v8:8988 > > Change-Id: I94d52866494102add91ca2d569a2044b08c9c593 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518556 > Commit-Queue: Alexei Filippov <alph@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60227} TBR=dgozman@chromium.org,alph@chromium.org,kozyatinskiy@chromium.org Change-Id: I26de645e425f0f7d5aa8212eeefda76dad695b78 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8988 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1522988Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#60229}
-
Alexei Filippov authored
Introduces the setMaxCollectedScriptsSize Debugger protocol method. If the max size is set, the debugger will hold collected (not referenced by other v8 heap objects) scripts up to the specified total size of their sources. BUG=v8:8988 Change-Id: I94d52866494102add91ca2d569a2044b08c9c593 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518556 Commit-Queue: Alexei Filippov <alph@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#60227}
-
- 29 Nov, 2018 1 commit
-
-
Aleksei Koziatinskii authored
This method was experimental and deprecated for a while. R=dgozman@chromium.org Bug: none Change-Id: I7d5a13a83f36ecc7a92300f690dff5c8bb26f8de Reviewed-on: https://chromium-review.googlesource.com/c/1354182Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#57920}
-
- 28 Sep, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
Sometimes we do not have promise on stack, e.g. Promise.reject call, but we need to attribute this pause with promise rejection. TBR=yangguo@chromium.org Bug: chromium:755728 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I03ca1e1cd6c21677f0a12ece626e2c8a1938437b Reviewed-on: https://chromium-review.googlesource.com/1249942Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56293}
-
- 13 Jul, 2018 1 commit
-
-
Johannes Henkel authored
This is in preparation of removing the using statements that are currently in third_party/inspector_protocol/lib/Collections_h.template. Once this is done I can update https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1135832 some more and eventually roll it into v8 (and chromium's third party). R=dgozman Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I75a7b291715f241e3b58fb97ac91a0b0ff0ca70b Reviewed-on: https://chromium-review.googlesource.com/1135968 Commit-Queue: Johannes Henkel <johannes@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#54422}
-
- 26 Apr, 2018 2 commits
-
-
Alexey Kozyatinskiy authored
This is a reland of 436faae0 Original change's description: > [inspector] added timeout for Debugger.evaluateOnCallFrame method > > R=dgozman@chromium.org,yangguo@chromium.org > > Bug: none > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel > Change-Id: I569899f245190ca2fa720bdb837db1263e8058d5 > Reviewed-on: https://chromium-review.googlesource.com/1023035 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52798} Bug: none Change-Id: I91219382b5dc45b54dd8e5c64d9f0d11c849b9c8 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Reviewed-on: https://chromium-review.googlesource.com/1030510 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#52818}
-
Michael Achenbach authored
This reverts commit 436faae0. Reason for revert: Introduces flakes: https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/24482 https://build.chromium.org/p/client.v8/builders/V8%20Win32/builds/13557 https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/25210 Original change's description: > [inspector] added timeout for Debugger.evaluateOnCallFrame method > > R=dgozman@chromium.org,yangguo@chromium.org > > Bug: none > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel > Change-Id: I569899f245190ca2fa720bdb837db1263e8058d5 > Reviewed-on: https://chromium-review.googlesource.com/1023035 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52798} TBR=dgozman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org Change-Id: I63ee0d19642856a7c0c2128bfa4c4620974d1919 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: none Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Reviewed-on: https://chromium-review.googlesource.com/1029910Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52800}
-
- 25 Apr, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
R=dgozman@chromium.org,yangguo@chromium.org Bug: none Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I569899f245190ca2fa720bdb837db1263e8058d5 Reviewed-on: https://chromium-review.googlesource.com/1023035 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#52798}
-
- 23 Apr, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
This function can be used to set breakpoint on any function call, including native functions without source code, for them new method is only one way to set breakpoint. R=dgozman@chromium.org Bug: chromium:828076 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Iae8f4805b6e860a7ca008041fdfbe75e43a1959c Reviewed-on: https://chromium-review.googlesource.com/1023128 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#52745}
-
- 22 Mar, 2018 1 commit
-
-
Yang Guo authored
R=jgruber@chromium.org, kozyatinskiy@chromium.org Bug: v8:178 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: Idee461c6ff6c8a14b01229ea6448e437f3db6dab Reviewed-on: https://chromium-review.googlesource.com/973202 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52151}
-
- 16 Feb, 2018 1 commit
-
-
Alexey Kozyatinskiy authored
We already cleanup these scripts on frontend side. It is crucial to cleanup them on backend side as well, since some web applications use following logic: get some data from network, add this data to buffer, try to parse buffer using JSON.parse. On each unsuccessfull JSON.parse we get another scriptFailedToParse event. Frontend logic of discarding scripts: https://goo.gl/FDtaWK Some idea of smarter logic here: track what script ids are reported using protocol and cleanup only script ids which reported not only as part of scriptFailedToParse event. R=alph@chromium.org Bug: chromium:810812 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ifd67764c232e4abc7dc6e8e69a651bf9ac0e381b Reviewed-on: https://chromium-review.googlesource.com/919834 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#51337}
-
- 02 Feb, 2018 1 commit
-
-
jgruber authored
This check verifies that all .h files in the src/ directory have an include guard of the form #ifndef V8_PATH_TO_FILE_H_ #define V8_PATH_TO_FILE_H_ // ... #endif // V8_PATH_TO_FILE_H_ The check can be skipped with a magic comment: // PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d Reviewed-on: https://chromium-review.googlesource.com/897487Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51079}
-
- 29 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
Some embedders primitive can trigger execution in current JavaScript instance or in another (e.g. MessageChannel). With this CL external async task can be local as well. R=dgozman@chromium.org Bug: chromium:661705 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I82c68a021c2c25bc67a706c4bfed8c1a2b2388c5 Reviewed-on: https://chromium-review.googlesource.com/792015 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49728}
-
- 23 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
If protocol client needs to make step-into async call: - pause before async call using any Debugger agent capabilities, - call Debugger.stepInto with breakOnAsyncCall flag, - wait for Debugger.paused event, this event will contain asyncCallStackTrace if async call is scheduled, - call Debugger.pauseOnAsyncCall on each known target, - resume execution in current debugger by Debugger.resume. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I40c56278e7b1ceafc3bf81608b8ca6716c2b3168 Reviewed-on: https://chromium-review.googlesource.com/773573 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Cr-Commit-Position: refs/heads/master@{#49594}
-
- 22 Nov, 2017 3 commits
-
-
Alexey Kozyatinskiy authored
Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. TBR=dgozman@chromium.org,jgruber@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I2c1a2b2e30ed69ccb61d10f08686f4edb09f50e4 Reviewed-on: https://chromium-review.googlesource.com/786274 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49591}
-
Clemens Hammacher authored
This reverts commit 3a41b697. Reason for revert: Break msvc: https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/250 Original change's description: > [inspector] introduced stackTraceId and externalAsyncTask API > > Sometimes we need to capture stack trace on one debugger and use it > later as a parent stack on another debugger (e.g. worker.postMessage). > > This CL includes following addition to our protocol and v8-inspector.h: > - added Runtime.StackTraceId, this id represents stack trace captured > on debugger with given id, > - protocol client can fetch Runtime.StackTrace by > Runtime.StacKTraceId using Debugger.getStackTrace method, > - externalParent field is added to Debugger.paused event, it may > contain external parent stack trace, > - V8Inspector::storeCurrentStackTrace captures current stack trace > and returns V8StackTraceId for embedder this id can be used as > argument for V8Inspector::externalAsyncTaskStarted and > V8Inspector::externalAsyncTaskFinished method. Any async stack > trace captured between these calls will get passed external stack > trace as external parent. These methods are designed to be called > on different debuggers. If async task is scheduled and started on > one debugger user should continue to use asyncTask* API, > - Debugger.enable methods returns unique debuggerId. > > Bug: chromium:778796 > Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539 > Reviewed-on: https://chromium-review.googlesource.com/754183 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49582} TBR=dgozman@chromium.org,pfeldman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org Change-Id: I9b52354fa0841e5148596cf594317f2e5fe508ea No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/786152Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49584}
-
Alexey Kozyatinskiy authored
Sometimes we need to capture stack trace on one debugger and use it later as a parent stack on another debugger (e.g. worker.postMessage). This CL includes following addition to our protocol and v8-inspector.h: - added Runtime.StackTraceId, this id represents stack trace captured on debugger with given id, - protocol client can fetch Runtime.StackTrace by Runtime.StacKTraceId using Debugger.getStackTrace method, - externalParent field is added to Debugger.paused event, it may contain external parent stack trace, - V8Inspector::storeCurrentStackTrace captures current stack trace and returns V8StackTraceId for embedder this id can be used as argument for V8Inspector::externalAsyncTaskStarted and V8Inspector::externalAsyncTaskFinished method. Any async stack trace captured between these calls will get passed external stack trace as external parent. These methods are designed to be called on different debuggers. If async task is scheduled and started on one debugger user should continue to use asyncTask* API, - Debugger.enable methods returns unique debuggerId. Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I16aba0d04bfcea90f3e187e635a0588c92354539 Reviewed-on: https://chromium-review.googlesource.com/754183Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49582}
-
- 06 Nov, 2017 1 commit
-
-
Alexey Kozyatinskiy authored
It is preparation step for step-into-worker. There are few changes: - added breakOnAsyncCall flag for Debugger.stepInto. When flag is set and async task is scheduled before step-into finished, we pause execution with additional Debugger.paused event. This event contains additional scheduledAsyncTaskId field. - added Debugger.pauseOnAsyncTask. This method will pause execution as soon as given async task is started. This mechanism is replacement for Debugger.scheduleStepIntoAsync which can not be used between multiple targets. As result we can split async task scheduling in one target and requesting break for this async task running in another target. R=pfeldman@chromium.org Bug: chromium:778796 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I77be0c880d91253d333c54a23a4c084e7b8549e9 Reviewed-on: https://chromium-review.googlesource.com/750071Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Pavel Feldman <pfeldman@chromium.org> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49127}
-