Skip to content

V
V8
Switch branch/tag
  1. 24 Mar, 2022 1 commit
    • Benedikt Meurer's avatar
      [debug] Hold on to promises weakly from the debugger's promise stack. · 3eb6b7ac
      Benedikt Meurer authored 
      The debugger maintains a stack of promises used for catch prediction
with promise builtins and async functions. Previously this stack would
hold on to the individual promises strongly, and subtle bugs that lead
to not properly cleaning up the stack in some corner cases would often
lead to significant memory issues (e.g. leaking whole iframes).

This refactors the PromiseOnStack to be

  (a) on the V8 heap, rather than allocating C++ structs with global
      handles pointing to the promises, and
  (b) hold on to the promises only weakly.

While this will not guarantee proper promise stack management, it will
at least ensure that edge cases don't lead to catastrophic (debugger
only) leaks.

Bug: chromium:1292063
Change-Id: I9c293ca2032de3a59e1e9624f132d37187805567
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545176
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79594}
      3eb6b7ac
  3. 11 Feb, 2022 1 commit
  5. 09 Feb, 2022 1 commit
    • Seth Brenith's avatar
      Avoid leaking Promises when detaching debugger · aae45ca8
      Seth Brenith authored 
      When the debugger is active and a Promise begins executing,
Isolate::PushPromise adds a global handle for that Promise. If the
debugger is no longer attached when the Promise finishes executing, then
there is no corresponding call to PopPromise which would clean up the
global handle. To avoid leaking memory in that case, we should clean up
the Promise stack when detaching the debugger.

Bug: v8:12613
Change-Id: I47a2c37713b43b482e23e2457e96fba5f52623f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3448949Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#79017}
      aae45ca8
  7. 02 Dec, 2021 1 commit
  9. 30 Nov, 2021 1 commit
  11. 15 Jul, 2021 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Fix DebugBreakType enum. · 5a4f8a08
      Benedikt Meurer authored 
      The order of the enum values is important for the BreakLocation
predicates. This wasn't an issue so far, since the DEBUG_BREAK_AT_ENTRY
case is anyways treated separately, but for the future I've added a
comment and fixed the order.

Drive-by-fix: Remove the useless `inline` markers on the predicates.

Bug: chromium:1162229, chromium:700516
Change-Id: I05653ac9b5ea225e30c5c2beeff809b8848c2ec7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026712
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75736}
      5a4f8a08
  13. 14 Jul, 2021 1 commit
    • Benedikt Meurer's avatar
      [refactor] Introduce dedicated WasmScript::SetBreakPointOnEntry(). · 95b2f02d
      Benedikt Meurer authored 
      Previously we had passed kOnEntryBreakpointPosition as a marker through
the regular SetBreakPointForScript() logic and handled that specially in
WasmScript, however this instrumentation breakpoint is special and gets
in the way of returning more information about a regular breakpoint in
case of crbug.com/700516, so I decided to just isolate that into it's
own method, especially since the only user already special-cases Wasm
anyways.

Bug: chromium:1162229, chromium:700516
Change-Id: Ie7966c1701365a4b03710d6dc32cc8278577ee3a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3026711
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75724}
      95b2f02d
  15. 10 Jun, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Consistent Step-In behavior for generator functions. · 887bacac
      Benedikt Meurer authored 
      This change addresses inconsistencies wrt. to stepping into generator
functions and breaking on the implicit initial yield. The new behavior
is the following:

 1. Stepping into a generator function doesn't trigger "generator
    stepping", but rather pauses right before the initial yield
    (assuming there a no non-simple parameters in between).
 2. When paused on the initial yield and stepping into or over, we also
    don't turn on "generator stepping" immediately, but rather return to
    the caller and only enter "generator stepping" on SuspendGenerator
    bytecodes that correspond to `yield`s or `await`s in the source
    code.

This matches the stepping behavior of regular functions more closely and
seems like a good compromise.

Fixed: chromium:901814
Change-Id: Ifc6c174011df1afea183e2c6ec21de27d72b17a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2949099
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75066}
      887bacac
  17. 01 Jun, 2021 1 commit
  19. 29 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored 
      The "Restart frame" feature was implemented as part of LiveEdit and
primarily used to support LiveEdit of active functions, but that was
previously disabled as part of https://crrev.com/c/2846892 because it's
too brittle and causes crashes when using seemingly unrelated features.
The "Restart frame" feature was also available as a context menu item
separately in the DevTools front-end, but that was also already removed
as part of https://crrev.com/c/2854681 earlier. So all uses are gone
now.

This change works by marking Debugger.restartFrame as deprecated and
having it respond with a ServerError all the time. It thus allows us to
remove a whole bunch of machinery that was essentially just put in
various places to support the restart_fp_ magic. In particular the
debugger no longer needs any machine specific builtins now.

Bug: chromium:1195927
Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
Fixed: chromium:1203606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
  21. 15 Mar, 2021 1 commit
    • Kim-Anh Tran's avatar
      [debugger] Consider close-by functions when setting a breakpoint · a7c8a3ea
      Kim-Anh Tran authored 
      This changes the behavior of SetBreakpointForScript to find more
accurate break positions.

Previously, setting a breakpoint would only consider the shared
function info that contained the requested position for setting a
breakpoint. More intuitively, a breakpoint should not necessarily
be set in a function that contains the position, but in the closest
breakable location that comes after the position we requested.

To achieve this we:
1. find the shared function info of the inner most function
that contains the requested_position.
This function's end position is used to find other shared function
infos in step 2.

2. search for all shared function infos that intersect with the
range [requested_position, inner_most_function.break_position[.

3. From the shared function infos extracted in 2, find the one
that has the closest breakable location to requested_position.

Also-By: bmeurer@chromium.org
Fixed: chromium:1137141
Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73392}
      a7c8a3ea
  23. 02 Mar, 2021 1 commit
  25. 15 Feb, 2021 1 commit
  27. 10 Dec, 2020 1 commit
    • Peter Marshall's avatar
      [inspector] Throw during debug-eval when accessing function prototypes · 9691c5cf
      Peter Marshall authored 
      Function prototypes can be lazily allocated. This means they go into the
temporary objects set that debug-eval uses to figure out if a write
will be side-effect free.

We were incorrectly classifying writes to function prototypes as
side-effect free because the prototype happened to be lazily allocated
when we first accessed it during debug-eval, but was actually reachable
from the function (not allocated temporarily).

To do this we introduced a way to temporarily turn off the temporary
object tracking, and we use it when lazily allocating function
prototypes.

This could mean that we incorrectly report side-effects when writing to
function prototypes for functions which were themselves created during
debug-eval side-effect free mode. However, it's unclear if this is a
problem, because function declarations set global variables which would
already throw due to side-effects.

Bug: chromium:1154193
Change-Id: I444a673662095f6deabaafdce3cdf3d86b71446d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2581968Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71692}
      9691c5cf
  29. 26 Nov, 2020 1 commit
  31. 20 Nov, 2020 1 commit
  33. 18 Nov, 2020 1 commit
  35. 17 Nov, 2020 1 commit
  37. 11 Aug, 2020 1 commit
  39. 07 May, 2020 1 commit
  41. 03 Feb, 2020 1 commit
    • Sigurd Schneider's avatar
      [debugger] Allow termination-on-resume when paused at a breakpoint · 9e52d5c5
      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: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66084}
      9e52d5c5
  43. 18 Dec, 2019 1 commit
  45. 04 Dec, 2019 1 commit
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored 
      This patch implements inspector support for private instance methods:

- Previously to implement brand checking for instances with private
  instance methods we store the brand both as the value with the brand
  itself as the key in the stances. Now we make the value the context
  associated with the class instead.
- To retrieve the private instance methods and accessors from the
  instances at runtime, we look into the contexts stored with the
  brands, and analyze the scope info to get the names as well as
  context slot indices of them.
- This patch extends the `PrivatePropertyDescriptor` in the inspector
  protocol to include optional `get` and `set` fields, and make the
  `value` field optional (similar to `PropertyDescriptor`s).
  Private fields or private instance methods are returned in the
  `value` field while private accessors are returned in the `get`
  and/or `set` field. Property previews for the instaces containing
  private instance methods and accessors are also updated similarly,
  although no additional protocol change is necessary since the
  `PropertyPreview` type can already be used to display accessors.

Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit

Bug: v8:9839, v8:8330
Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
  47. 22 Nov, 2019 1 commit
  49. 15 Nov, 2019 1 commit
  51. 13 Sep, 2019 1 commit
  53. 23 Aug, 2019 1 commit
  55. 22 Aug, 2019 2 commits
  57. 12 Jul, 2019 1 commit
  59. 13 Jun, 2019 1 commit
  61. 24 May, 2019 1 commit
  63. 23 May, 2019 1 commit
  65. 22 May, 2019 1 commit
  67. 21 May, 2019 1 commit
  69. 08 May, 2019 1 commit
  71. 09 Apr, 2019 1 commit
  73. 04 Apr, 2019 1 commit
  75. 27 Feb, 2019 1 commit
  77. 01 Feb, 2019 1 commit