1. 23 Dec, 2020 1 commit
  2. 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
  3. 22 Mar, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] changed a way of preserving stepping between tasks · 760c56bd
      kozyatinskiy authored
      Indisputable profit:
      - correct break location in next task (see tests),
      - stepOver with async await never lands in random code (see related test and issue),
      - inspector doesn't store current stepping state in debugger agent and completely trust V8 - step to new inspector-V8 design (I will finish design doc soon).
      - willExecuteScript and didExecuteScript instrumentation could be removed from code base - reduce probability of future errors.
      - finally - less code,
      - stepping implementation in V8 makes another step to follow our stepping strategy (stepOut should do stepInto and break when exit current frame) (another one one page design doc based on @aandrey comment is coming),
      - knowledge about existing of context groups is still inspector-only.
      
      Disputable part is related to super rare scenario when in single isolate we have more then one context group id with enabled debugger agent:
      - if one agent request break in own context (stepping, pause, e.t.c.) then we ignore all breaks in another agent. From one hand it looks like good: user clicks stepInto and they don't expect that execution could be paused by another instance of DevTools in unobservable from current DevTools way (second DevTools will get paused notification and run nested message loop). From another hand we shouldn't ignore breakpoints or debugger statement never. In general, I think that proposed behavior is rathe feature then issue.
      - and disadvantage, on attempt to break in non-target context group id we just call StepOut until reach target context group id, step out call could deoptimize code in non related to current debugger agent context. But break could happens only in case of debugger stmt or breakpoint - sound like minor issue. Ignoring break on exception sounds like real issue but by module of rareness of this case I think we can ignore this.
      
      Implementation details:
      - when debugger agent request break for any reason it passes target context group id to V8Debugger - last agent requesting break is preferred.
      - when V8Debugger gets BreakProgramRequested notification from V8, it checks current context group id against target context group id, if they match then just process break as usual otherwise makes StepOut action,
      - debug.cc at the end of microtask if last_scheduled_action is StepOut, schedules StepIn and will break on first instruction in next task.
      
      BUG=chromium:654022
      R=dgozman@chromium.org,yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2748503002
      Cr-Commit-Position: refs/heads/master@{#44034}
      760c56bd
  4. 07 Mar, 2017 1 commit