1. 04 Nov, 2021 1 commit
    • Tim van der Lippe's avatar
      Revert "[inspector] Use side-effect free debug evaluate for inherited accessors." · e9d36117
      Tim van der Lippe authored
      This reverts commit f9ebad01.
      
      Reason for revert: suspected root cause of crbug.com/1257806 Additionally, this patch might actually be incorrect as we eagerly evaluate native accessors, which can only happen if the debugger is running.
      
      Original change's description:
      > [inspector] Use side-effect free debug evaluate for inherited accessors.
      >
      > Replace the hard-coded blocklist ("Response.body" and "Request.body") in
      > the V8 inspector with proper side-effect free debug evaluate. This is
      > otherwise a non-functional change and in particular preserves the
      > behavior of reporting accessors as (own) data properties. That will be
      > tackled in a follow-up CL.
      >
      > This CL is possible because with https://crrev.com/c/3056879 Blink now
      > properly marks accessors as side-effect free consistently with what the
      > V8 inspector had done before.
      >
      > Doc: http://doc/1gLyyOlssS5zyCSEyybVC-5sp0UnNJj2hBoFyf6ryrTc
      > Bug: chromium:829571, chromium:1076820, chromium:1119900
      > Change-Id: Idb256accaf4cfb5db5982b3eb06ddcef588be635
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062573
      > Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      > Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      > Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#76019}
      
      Bug: chromium:829571, chromium:1076820, chromium:1119900, chromium:1257806
      Fixed: chromium:1265372
      Change-Id: Ia31a3022aaa9ddeae1f01eaa90e345f8bdbb21c9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259653
      Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77708}
      e9d36117
  2. 28 Oct, 2021 1 commit
  3. 15 Oct, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Properly catch side effecting iterators. · cb08942d
      Benedikt Meurer authored
      Array spread syntax `[...obj]` is compiled to a special bytecode that
      tries to take fast-paths for values special kinds of `obj`s, including
      Set, Map, and Array iterator instances. But these fast-paths skip the
      side-effect checks of `Runtime.evaluate` and friends, and thus lead to
      surprises for developers.
      
      This CL alters the behavior to always call the `next()` builtins when
      the debugger is active to make sure we catch the side effects correctly.
      
      Fixed: chromium:1255896
      Change-Id: If3fc48a119cfa791c4fde7b5c586acc22dd973e7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226329
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77409}
      cb08942d
  4. 12 Oct, 2021 1 commit
    • Kim-Anh Tran's avatar
      [debug] Capture more cases for instrumentation breakpoints · 0c3fdff2
      Kim-Anh Tran authored
      The previous implementation would not explicitly send
      `Debugger.paused` events for instrumentation breakpoints
      if they were to overlap with breaks due to:
      * regular breakpoints
      * OOM
      * exceptions
      * asserts
      
      This CL is a step towards making sure that a separate
      `Debugger.paused` event is always sent for an instrumentation
      breakpoint. In some cases where we have overlapping reasons
      but only know of one, the 'instrumentation' reason,
      we still just send out one paused event with the reason
      being `instrumentation`.
      
      Drive-by: send instrumentation notification to all sessions,
      remember which breakpoints are instrumentation breakpoints
      
      Bug: chromium:1229541, chromium:1133307
      Change-Id: Ie15438f78b8b81a89c64fa291ce7ecc36ebb2182
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211892Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77333}
      0c3fdff2
  5. 01 Oct, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Consistently treat promise rejections as side-effecting. · 0195a5eb
      Benedikt Meurer authored
      Previously we'd treat %_AsyncFunctionReject (and %AsyncFunctionReject)
      as side-effect free (in async functions), but that's not correct, since
      promise rejections have side-effects (at the very least triggering the
      unhandled promise rejection machinery in the browser).
      
      This required a minor refactoring as previously we'd classify functions
      as side-effecting or not depending on whether they contain any calls to
      side-effecting intrinsics, no matter whether this call is actually
      executed or not. That would break REPL mode however if we'd generally
      treat all async functions with %_AsyncFunctionReject intrinsic calls as
      side-effecting, so instead of performing the intrinsic checks ahead of
      time, we now perform the test at execution time.
      
      Before: https://imgur.com/5BvJP9d.png
      After: https://imgur.com/10FanNr.png
      Fixed: chromium:1249275
      Change-Id: Ib06f945ba21f1e06ee9b13a1363fad342464fd9a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3197712
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77183}
      0195a5eb
  6. 30 Sep, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Align async task frame reporting for `await`. · d6c01059
      Benedikt Meurer authored
      The V8 Inspector was sending an additional frame as part of async stack
      traces for async functions, which pointed to the first executed `await`
      in the async function. This is leaking an implementation detail of how
      (and more precisely when) the inspector decides to collect this stack
      trace. From the users perspective the async part of the stack trace is
      supposed to capture what happened _prior to the task_ - meaning in case
      of async functions: What lead to the execution of the async function.
      This is reflected by the fact that the DevTools front-end (and the V8
      Inspector itself) performs post-processing on these async call stacks,
      removing the misleading top frame from it. But this post-processing is
      not applied consistently to all async stack traces (i.e. the Console
      message stack traces don't get this), and potentially also not applied
      consistently across consumers of the Chromium debugger backend.
      
      Instead the V8 Inspector now removes the top frame itself and thus
      reports `await` consistently with how other async tasks are reported to
      debugger front-ends.
      
      Note: This preserves backwards compatibility with old versions of
      devtools-frontend, which do post-processing (for the Call Stack) only on
      async stack traces marked with "async function", while we now mark these
      async stack traces with "await" instead (aligned with what the front-end
      is using as user visibile string anyways in the Call Stack section, and
      this matching will be updated in a separate follow up CL to look for
      "await" instead of "async function").
      
      Before: https://imgur.com/kIrWcIc.png
      After: https://imgur.com/HvZGqiP
      Fixed: chromium:1254259
      Bug: chromium:1229662
      Change-Id: I57ce051a28892177b6b96221f083ae957f967e52
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193535
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarKim-Anh Tran <kimanh@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77157}
      d6c01059
  7. 17 Sep, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Make `ArrayBuffer.[[ArrayBufferData]]` deterministic. · 833b3c96
      Benedikt Meurer authored
      Previously the internal `[[ArrayBufferData]]` property for `ArrayBuffer`
      objects reported by the inspector (and used by the DevTools front-end to
      identify `ArrayBuffer`s and `WebAssembly.Memory`s using the same backing
      store) simply contained a hex string representation of the backing store
      pointer. However that unnecessarily leaks internal addresses and more
      importantly is not deterministic, which complicates tests (just blew up
      on layout tests).
      
      This CL introduces an automatically incremented `BackingStore::id()`,
      which is used instead now and is deterministic.
      
      Bug: chromium:1199701, chromium:1163802, chromium:1249961
      Change-Id: I8ee47009cd825cfdbe00230f617c87c90508ab2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162144
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76893}
      833b3c96
  8. 16 Aug, 2021 1 commit
    • Santiago Aboy Solanes's avatar
      Revert "Reland "[debugger] Try to trigger pause-on-oom flakes with an extra printf"" · c357f447
      Santiago Aboy Solanes authored
      This reverts commit a4a152ec.
      
      Reason for revert: We haven't seen the flakes in a while, we can re-enable functionality
      
      Original change's description:
      > Reland "[debugger] Try to trigger pause-on-oom flakes with an extra printf"
      >
      > This is a reland of 8f7e9158
      >
      > Original change's description:
      > > [debugger] Try to trigger pause-on-oom flakes with an extra printf
      > >
      > > We have an issue that we can't repro locally. Enable back the
      > > pause-on-oom tests with an extra printf with DEBUG. We will be able to
      > > better assess the failures when they appear on the bot.
      > >
      > > Bug: v8:10876
      > > Change-Id: I066539c4b5865ecb6f2e589e9543e8c9ebd4830b
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2474782
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70558}
      >
      > Bug: v8:10876
      > Change-Id: Ice31c9455830da320ab057293c341f69e1f0c510
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2484799
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70643}
      
      Bug: v8:10876
      Change-Id: I901d31e1e92bfef0b2917ea611354618e5cda585
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071404Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76302}
      c357f447
  9. 06 Aug, 2021 1 commit
  10. 04 Aug, 2021 3 commits
  11. 03 Aug, 2021 1 commit
  12. 29 Jun, 2021 1 commit
  13. 17 Jun, 2021 1 commit
  14. 10 Jun, 2021 2 commits
    • Dylan Cutler's avatar
      Use more inclusive language in ./test/inspector/debugger/. · 479df6a2
      Dylan Cutler authored
      Bug: chromium:1097184
      Change-Id: Ifa64885cb74ffe05ef56aca59150c89d8f11dd1d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2945276
      Auto-Submit: Dylan Cutler <dylancutler@google.com>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75067}
      479df6a2
    • 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
  15. 09 Jun, 2021 1 commit
  16. 01 Jun, 2021 1 commit
  17. 20 May, 2021 1 commit
  18. 14 May, 2021 2 commits
  19. 12 May, 2021 1 commit
  20. 10 May, 2021 1 commit
  21. 07 May, 2021 1 commit
    • Sigurd Schneider's avatar
      Fix monitor for arrow functions · 9c40b865
      Sigurd Schneider authored
      Our current logic for the console API's monitor implementation relies on
      JavaScript's arguments array. In arrow functions, this results in an
      error, resulting missing print statements from monitor.
      
      This CL at least re-enables the print statements, but does not print the
      arguments in the case of arrow functions.
      
      Change-Id: Ibf6c2a0fb5e0cc911c257520a59a875992fe3777
      Bug: chromium:1206137
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880216Reviewed-by: 's avatarPhilip Pfaffe <pfaffe@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74437}
      9c40b865
  22. 06 May, 2021 1 commit
  23. 05 May, 2021 1 commit
  24. 30 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Don't attach source positions to implicit returns. · 379331b7
      Benedikt Meurer authored
      Previously we'd attach source positions to implicit returns that are
      generated when leaving an async function with a promise rejection. This
      was due to the use of `kNoSourcePosition` on the `end_position` in the
      `ReturnStatement` nodes as indicator to pick the return position from
      the function literal, instead of really not putting a source position on
      that specific `Return` bytecode.
      
      This CL adds a dedicated marker to `ReturnStatement` to express that the
      `BytecodeGenerator` should put the return position from the function
      literal there instead of overloading the meaning of `kNoSourcePosition`.
      
      Bug: chromium:901819, chromium:782461
      Fixed: chromium:1199919, chromium:1201706
      Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74301}
      379331b7
  25. 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
  26. 28 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Disallow LiveEdit of active frames. · 53fc4807
      Benedikt Meurer authored
      Previously we'd allow to replace the source of functions that are on the
      current execution stack under certain conditions, but this has resulted
      in an endless stream of bugs due to weird edge cases, and so we're now
      limiting LiveEdit to functions that don't have any activation (including
      not a suspended generator / async function activation).
      
      We might eventually add the ability to LiveEdit functions with
      activations and have them "upgrade upon next invocation", but that
      doesn't seem to be an extremely important use case right now.
      
      Fixed: chromium:1195927
      Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74249}
      53fc4807
  27. 12 Apr, 2021 1 commit
  28. 09 Apr, 2021 3 commits
  29. 22 Mar, 2021 2 commits
  30. 17 Mar, 2021 2 commits
  31. 16 Mar, 2021 1 commit
  32. 15 Mar, 2021 1 commit