1. 13 Jan, 2021 1 commit
  2. 11 Jan, 2021 1 commit
  3. 29 Dec, 2020 1 commit
    • Benedikt Meurer's avatar
      [debug] Make JSArrayBuffer (pre)views into internal properties. · 2cab7ae9
      Benedikt Meurer authored
      For JSArrayBuffer instances (which map to both v8::ArrayBuffer and
      v8::SharedArrayBuffer), we add a couple of synthetic views to its
      ValueMirror to make it easy for developers to peak into the contents of
      the JSArrayBuffer. These were previously real properties, but that's
      just wrong (both intuitively and semantically), and they should instead
      be internal properties.
      
      Drive-by-fix: The [[IsDetached]] internal property should only be shown
      on actually detached JSArrayBuffer's to reduce visual clutter. And for
      detached JSArrayBuffers creating views on them throws TypeErrors per
      specification, so we shouldn't attempt to display views on them.
      
      Bug: v8:9308, chromium:1162229
      Change-Id: Ia006de7873ca4b27aae7d00d46e1b69d2e326449
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2606047
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71892}
      2cab7ae9
  4. 23 Dec, 2020 1 commit
  5. 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
  6. 27 Oct, 2020 1 commit
    • Simon Zünd's avatar
      Fix crash in JSPromise::Resolve when 'then' getter is terminating · 4c28563b
      Simon Zünd authored
      The crash scenario is as follows:
        1) Add a getter for 'then' to the Object prototype that is
           considered side-effecting.
        2) Evaluate a simple string using 'REPL' mode with side-effect checks
           enabled.
           Note: REPL mode is not strictly necessary, but it causes a 'then'
           lookup as the evaluation result is not a promise.
        3) Calling the 'then' getter causes a termination exception, due
           to the side-effect check. JSPromise::Resolve then tries to
           put the termination exception as the reject reason, which causes
           a CHECK failure.
      
      The solution is to check for termination in the "abrupt completion"
      case when 'then' was retrieved.
      
      Bug: chromium:1140845
      Change-Id: I72b644cd49355cea40f599fcbe80264e99ed7bd6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501283Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70785}
      4c28563b
  7. 18 Oct, 2020 1 commit
    • Dmitry Gozman's avatar
      [inspector] Prepend isolateId to remoteObjectId · 66725a53
      Dmitry Gozman authored
      This changes remoteObjectId format from
      "{injectedScriptId:123,id:456}" to "<isolateId>.<contextId>.<id>".
      
      Prepending isolateId fixes the problem that
      remote object ids clash between processes. This is especially
      troubling during cross-process navigation in Chromium, see bug.
      
      We also stop producing and parsing unnecessary json for object ids.
      
      Drive-by: fixed some tests dumping object ids. Most tests avoid
      dumping unstable values like ids, but there were few that still did.
      
      BUG=chromium:1137143
      
      Change-Id: Ia019757fb95704ccb718d3ea6cc54bde1a133382
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461731
      Commit-Queue: Dmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70592}
      66725a53
  8. 01 Oct, 2020 2 commits
    • Andrey Kosyakov's avatar
      DevTools: add support for injecting bindings by context name · abacd4c1
      Andrey Kosyakov authored
      This adds support for injecting binding into contexts other than
      main based on the context name (AKA isolated world name in Blink
      terms). This would simplify a common use case for addBinding in
      Puppeteer and other automation tools that use addBinding to expose
      a back-channel for extension code running in an isolated world by
      making bindings available to such code at an early stage and in a
      race-free manner (currently, we can only inject a binding into
      specific context after the creation of the context has been reported
      to the client, which typically introduces a race with other evals
      the client may be running in the context).
      
      Change-Id: I66454954491a47a0c9aa4864f0aace4da2e67d3a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440984Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarPavel Feldman <pfeldman@chromium.org>
      Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70266}
      abacd4c1
    • Andrey Kosyakov's avatar
      DevTools: ensure binding is only exposed into the specified context · a65c5fb7
      Andrey Kosyakov authored
      ... when addBinding is called with contextId. Previously, due to
      a subtle type, we exposed bidings added with executionContextId to
      all contexts created after the binding was added.
      
      Also, do not persist context-specific bindings to agent state,
      as context ids don't make sense across the process.
      
      This also adds a test instrastructure to create additional context in
      given context group.
      
      Change-Id: I1b3e96cb65b756424bc7872d200bbbf41e4c30b8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440982Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Andrey Kosyakov <caseq@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70261}
      a65c5fb7
  9. 28 Sep, 2020 1 commit
  10. 18 Aug, 2020 1 commit
  11. 27 Jul, 2020 1 commit
  12. 24 Jul, 2020 1 commit
    • Benedikt Meurer's avatar
      [inspector] Add internal property to identify detached ArrayBuffers. · b886e153
      Benedikt Meurer authored
      This adds an internal property [[IsDetached]] to the inspector preview
      of ArrayBuffer instances, which indicates whether the ArrayBuffer was
      detached (i.e. transfered via `postMessage`). Previously it was rather
      impossible to tell whether an ArrayBuffer was detached, you had to know
      that V8 violates the ECMAScript specification and simply sets the
      byteLength accessor to 0 upon detaching an ArrayBuffer (but even then it
      was still impossible to tell whether that ArrayBuffer wasn't simply an
      empty one from the get go).
      
      Before: https://imgur.com/UcOF83c
      After: https://imgur.com/WjmTehZ
      
      Fixed: chromium:1109102
      Change-Id: I8fb6e2be2fbfe5c62b05dc9d2a0f18378eb4de6c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2316075
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      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@{#69034}
      b886e153
  13. 02 Jul, 2020 1 commit
  14. 15 May, 2020 1 commit
  15. 14 May, 2020 1 commit
  16. 07 May, 2020 1 commit
  17. 28 Apr, 2020 1 commit
  18. 17 Apr, 2020 1 commit
  19. 16 Apr, 2020 1 commit
    • Ulan Degenbaev's avatar
      [inspector] Fix handling of on-heap TypedArrays in queryObjects() · 5ee9cf87
      Ulan Degenbaev authored
      On-heap TypedArrays have empty ArrayBuffers that are not supposed to be
      accessed directly. Such ArrayBuffers materialize properly when accessed
      via their TypedArrays.
      
      The queryObjects() sidesteps the bottleneck and finds empty ArrayBuffers
      by iterating the heap. When preview TypedArrays are constructed for the
      found ArrayBuffers, they get nullptr data pointers.
      
      This CL converts all on-heap TypedArrays into off-heap TypedArrays in
      queryObjects to make sure that all found ArrayBuffers are valid.
      
      Bug: chromium:992442
      Change-Id: Ie77d1e75aa2007b4a976c72206b9a4e215c9ef53
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2150601
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67174}
      5ee9cf87
  20. 09 Apr, 2020 1 commit
  21. 17 Mar, 2020 1 commit
  22. 18 Feb, 2020 1 commit
  23. 28 Jan, 2020 1 commit
  24. 27 Jan, 2020 1 commit
    • Peter Marshall's avatar
      [inspector] Add a test for const declaration and side effects · 73f4ac62
      Peter Marshall authored
      Add a test that does the same thing the devtools-frontend does when
      evaluating console inputs.
      
      1) Declare a const variable with throwOnSideEffect=true. This should
      throw.
      2) Declare the same const variable with throwOnSideEffect=false.
      This should successfully declare the variable.
      
      Previously it could be the case that even though we threw in 1), the
      variable would fail to be initialized in 2) with a re-declaration
      error.
      
      Bug: chromium:1043151
      Change-Id: I1a6126b518f7bb3788c39b9f8e3adb8850aa962a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016587
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65991}
      73f4ac62
  25. 22 Jan, 2020 1 commit
  26. 21 Jan, 2020 1 commit
  27. 18 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Store JSMessageObject on rejected promises · b15c02d0
      Simon Zünd authored
      When V8 throws an uncaught exception, we store a JSMessageObject
      with a stack trace and source positions on the isolate itself.
      The JSMessageObject can be retrieved by a TryCatch scope
      and is used by the inspector to provide additional information to the DevTools
      frontend (besides the exception).
      
      Introducing top-level await for REPL mode causes all thrown exceptions
      to be turned into a rejected promise. The implicit catch block that does this
      conversion clears the JSMessageObject from the isolate as to not leak memory.
      
      This CL preserves the JSMessageObject when the debugger is active and stores
      the JSMessageObject on the rejected promise itself. The inspector is changed
      to retrieve the JSMessageObject in the existing catch handler and pass the
      information along to the frontend.
      
      Drive-by: This CL removes a inspector test that made assumptions when a promise
      is cleaned up by the GC. These assumptions no longer hold since we hold on to
      the promise longer.
      
      Bug: chromium:1021921
      Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65497}
      b15c02d0
  28. 28 Nov, 2019 1 commit
  29. 06 Nov, 2019 1 commit
  30. 27 Sep, 2019 1 commit
  31. 02 Sep, 2019 1 commit
  32. 23 Aug, 2019 1 commit
  33. 09 Aug, 2019 1 commit
  34. 08 Aug, 2019 1 commit
  35. 07 Aug, 2019 1 commit
  36. 18 Jun, 2019 1 commit
  37. 12 Jun, 2019 2 commits
  38. 11 Jun, 2019 1 commit