1. 18 Oct, 2018 1 commit
  2. 09 Aug, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] added V8InspectorClient::resourceNameToUrl · dbfcc487
      Alexey Kozyatinskiy authored
      Some clients (see Node.js) use platform path as ScriptOrigin.
      Reporting platform path in protocol makes using protocol much harder.
      This CL introduced V8InspectorClient::resourceNameToUrl method that
      is called for any reported using protocol url.
      V8Inspector uses url internally as well so protocol client may generate
      pattern for blackboxing with file urls only and does not need to build
      complicated regexp that covers files urls and platform paths on
      different platforms.
      
      R=lushnikov@chromium.org
      TBR=yangguo@chromium.org
      
      Bug: none
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Iff302e7441df922fa5d689fe510f5a9bfd470b9b
      Reviewed-on: https://chromium-review.googlesource.com/1164624
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55029}
      dbfcc487
  3. 23 Jul, 2018 1 commit
  4. 04 Jun, 2018 1 commit
  5. 31 May, 2018 1 commit
  6. 07 May, 2018 1 commit
  7. 02 Feb, 2018 1 commit
  8. 14 Dec, 2017 1 commit
  9. 23 Nov, 2017 1 commit
  10. 22 Nov, 2017 3 commits
    • Alexey Kozyatinskiy's avatar
      Reland [inspector] introduced stackTraceId and externalAsyncTask API · 885a5669
      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: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49591}
      885a5669
    • Clemens Hammacher's avatar
      Revert "[inspector] introduced stackTraceId and externalAsyncTask API" · 4379533c
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49584}
      4379533c
    • Alexey Kozyatinskiy's avatar
      [inspector] introduced stackTraceId and externalAsyncTask API · 3a41b697
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49582}
      3a41b697
  11. 21 Nov, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] reworked async instrumentation for promises · ed9b2072
      Alexey Kozyatinskiy authored
      Old instrumentation was designed to collect promise creation stack and
      promise scheduled stack together. In DevTools for last 6 months we
      show only creation stack for promises. We got strong support from users
      for new model. Now we can drop support for scheduled stacks and
      simplify implementation.
      
      New promise instrumentation is straightforward:
      - we send kDebugPromiseThen when promise is created by .then call,
      - we send kDebugPromiseCatch when promise is created by .catch call,
      - we send kDebugWillHandle before chained callback and kDebugDidHandle
        after chained callback,
      - and we send separate kDebugAsyncFunctionPromiseCreated for internal
        promise inside async await function.
      
      Advantages:
      - we reduce amount of captured stacks (we do not capture stack for
        promise that constructed not by .then or .catch),
      - we can consider async task related to .then and .catch as one shot
        since chained callback is executed once,
      - on V8 side we can implement required instrumentation using only
        promise hooks,
      
      Disadvantage:
      - see await-promise test, sometimes scheduled stack was useful since we
        add catch handler in native code,
      
      Implementation details:
      - on kInit promise hook we need to figure out why promise was created.
        We analyze builtin functions until first user defined function on
        current stack. If there is kAsyncFunctionPromiseCreate function then
        we send kDebugAsyncFunctionPromiseCreated event. If there is
        kPromiseThen or kPromiseCatch then only if this function is bottom
        builtin function we send corresponded event to inspector. We need it
        because Promise.all internally calls .then and in this case we have
        Promise.all and Promise.then on stack at the same time and we do not
        need to report this internally created promise to inspector.
      
      Bug: chromium:778796
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I53f47ce8c5c4a9897655c3396c249ea59529ae47
      Reviewed-on: https://chromium-review.googlesource.com/765208
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49553}
      ed9b2072
  12. 16 May, 2017 1 commit
  13. 11 May, 2017 1 commit
  14. 10 May, 2017 1 commit
  15. 09 May, 2017 1 commit
  16. 28 Apr, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] better stacks for promises · f2bd913c
      kozyatinskiy authored
      - we should always set creation async stack if it's available regardless existing of current parent async stack,
      - we should cleanup parent link iff there is no creation and schedule async stack for parent.
      
      Let's consider example: Promise.resolve().then(x => x).then(x => x), there is three promises which will call following instrumentation:
      1) created #1 (Promise.resolve()) - collected stack #1
      2) scheduled #1 - collected stack #2
      3) created #2 with #1 as parent (first .then) - collected stack #3
      4) created #3 with #2 as parent (first .then) - collected stack #4
      5) started #2 - use stack #2 as scheduled
      6) scheduled #2 - collected stack #6
      7) finished #2
      8) started #3 - use stack #6 as scheduled
      9) scheduled #3 - collected stack #7
      10) finished #3
      
      If we collect stacks between step 4 and 5, it's possible to collect scheduled stack #2 but still have creation stack for #2 - stack #3 - so we always need to add creation event if scheduled is collected.
      
      If we collect stacks between created and scheduled we should not remove parent link even if parent was not scheduled yet.
      
      BUG=v8:6189
      R=dgozman@chromium.org
      
      Review-Url: https://codereview.chromium.org/2844753002
      Cr-Commit-Position: refs/heads/master@{#44990}
      f2bd913c
  17. 20 Apr, 2017 1 commit
  18. 18 Apr, 2017 3 commits
  19. 12 Apr, 2017 1 commit
  20. 26 Jan, 2017 1 commit
  21. 26 Sep, 2016 1 commit
  22. 21 Sep, 2016 2 commits
  23. 06 Sep, 2016 1 commit
  24. 01 Sep, 2016 1 commit
  25. 31 Aug, 2016 2 commits