1. 23 Aug, 2017 1 commit
  2. 21 Aug, 2017 1 commit
  3. 02 Aug, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] move breakpoint management to native · cd9e86a5
      Alexey Kozyatinskiy authored
      My goal was to move breakpoint API to native with minimal changes around, so on inspector side we use v8::debug::BreakpointId instead of String16, on v8::internal::Debug we use i::BreakPoint object instead of break point object created inside of debug.js.
      
      There are a lot of opportunities how we can improve breakpoints (at least we can avoid some of linear lookups to speedup implementation) but I think that as first step we need to remove mirrors/debug.js APIs.
      
      Drive by: debugger-script.js and usage of debugger context in inspector code base.
      
      R=yangguo@chromium.org,jgruber@chromium.org,clemensh@chromium.org
      
      Bug: v8:5510,chromium:652939
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I0b17972c39053dd4989bbe26db2bb0b88ca378f7
      Reviewed-on: https://chromium-review.googlesource.com/593156Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47091}
      cd9e86a5
  4. 31 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] don't call clearAllBreakpoints · f2fe13f6
      Alexey Kozyatinskiy authored
      This call from inspector side is redundant, V8 will clear all breakpoints on removing debug delegate in v8::internal::Debug::Unload method.
      
      In any case for correct support of multiclient we need to clear breakpoints in V8DebuggerAgentImpl::disable method.
      
      R=dgozman@chromium.org
      
      Bug: v8:5510,chromium:652939
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: I66f9b97797860bad28884a099928d54ac3560428
      Reviewed-on: https://chromium-review.googlesource.com/592281
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47022}
      f2fe13f6
  5. 28 Jul, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] move SetScriptSource call to native · 6b0bf165
      Alexey Kozyatinskiy authored
      To avoid using debugging context and debugger-script.js on inspector side we can move SetScriptSource call to v8::internal::Debug. Theoretically we can move live edit implementation to native completely but since it will be reimplemented it looks redundant.
      
      R=yangguo@chromium.org,jgruber@chromium.org
      
      Bug: chromium:652939
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: Id09492c2d2a93efbde429c9cc1bc181d5fdda19b
      Reviewed-on: https://chromium-review.googlesource.com/590736
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46985}
      6b0bf165
  6. 27 Jul, 2017 1 commit
  7. 07 Jun, 2017 1 commit
  8. 06 Jun, 2017 1 commit
  9. 05 Jun, 2017 1 commit
  10. 01 Jun, 2017 1 commit
    • dgozman's avatar
      [inspector] Support multiple sessions per context group · 375bea1c
      dgozman authored
      This patch adds ability to connect multiple sessions to a single context group. This is an experimental feature, which is already supported in test harness.
      
      So far covered runtime domain with tests (and found a bug thanks to the test). More tests to follow in next patches, probably with code adjustments as well.
      
      BUG=chromium:590878
      
      Review-Url: https://codereview.chromium.org/2906153002
      Cr-Commit-Position: refs/heads/master@{#45667}
      375bea1c
  11. 16 May, 2017 2 commits
  12. 25 Apr, 2017 2 commits
  13. 20 Apr, 2017 4 commits
  14. 18 Apr, 2017 3 commits
  15. 17 Apr, 2017 1 commit
  16. 12 Apr, 2017 1 commit
  17. 30 Mar, 2017 1 commit
  18. 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
  19. 13 Mar, 2017 1 commit
  20. 06 Mar, 2017 1 commit
  21. 09 Feb, 2017 1 commit
  22. 07 Feb, 2017 2 commits
  23. 03 Feb, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] V8DebuggerAgent cleanup · 3a4f5faf
      kozyatinskiy authored
      V8DebuggerAgentImpl::m_skipAllPaused is moved to V8Debugger.
      V8DebuggerAgentImpl::didPaused doesn't return shouldBreak flag and called only when break is required and stack trace presented.
      V8DebuggerAgentImpl doesn't store paused context.
      Logic of conversion step-next at return into step-in is moved to debug.cc.
      
      BUG=none
      R=dgozman@chromium.org,yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2668763003
      Cr-Commit-Position: refs/heads/master@{#42907}
      3a4f5faf
  24. 26 Jan, 2017 2 commits
  25. 25 Jan, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] change target promise for kDebugWillHandle & kDebugDidHandle · cb545a8c
      kozyatinskiy authored
      - kDebugPromiseCreated(task, parent_task)
      This event occurs when promise is created (PromiseHookType::Init). V8Debugger uses this event to maintain task -> parent task map.
      
      - kDebugEnqueueAsyncFunction(task)
      This event occurs when first internal promise for async function is created. V8Debugger collects stack trace at this point.
      
      - kDebugEnqueuePromiseResolve(task),
      This event occurs when Promise fulfills with resolved status. V8Debugger collects stack trace at this point.
      
      - kDebugEnqueuePromiseReject(task),
      This event occurs when Promise fulfills with rejected status. V8Debugger collects stack trace at this point.
      
      - kDebugPromiseCollected,
      This event occurs when Promise is collected and no other chained callbacks can be added. V8Debugger removes information about async task for this promise.
      
      - kDebugWillHandle,
      This event occurs when chained promise function (either resolve or reject handler) is called. V8Debugger installs parent promise's stack (based on task -> parent_task map) as current if available or current promise's scheduled stack otherwise.
      
      - kDebugDidHandle,
      This event occurs after chained promise function has finished. V8Debugger restores asynchronous call chain to previous one.
      
      With this change all instrumentation calls are related to current promise (before WillHandle and DidHandle were related to next async task).
      
      Before V8Debugger supported only the following:
      - asyncTaskScheduled(task1)
      - asyncTaskStarted(task1)
      - asyncTaskFinished(task1)
      
      Now V8Debugger supports the following:
      - asyncTaskScheduled(parent_task)
      ..
      - asyncTaskCreated(task, parent_task),
      - asyncTaskStarted(task), uses parent_task scheduled stack
      - asyncTaskScheduled(task)
      - asyncTaskFinished(task)
      
      Additionally: WillHandle and DidHandle were migrated to PromiseHook API.
      
      More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE
      
      BUG=v8:5738
      R=dgozman@chromium.org,gsathya@chromium.org,yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2650803003
      Cr-Commit-Position: refs/heads/master@{#42644}
      cb545a8c
  26. 24 Jan, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] implemented blackboxing inside v8 · ac50c79a
      kozyatinskiy authored
      V8 has internal mechanism to ignore steps and breaks inside internal scripts, in this CL it's reused for blackboxing implementation.
      Advantages:
      - much faster blackboxing implementation (before we at least wrap and collect current call stack for each step),
      - get rid of StepFrame action and potential pause in blackboxed code after N StepFrame steps,
      - simplification of debugger agent logic.
      Disadvtanges:
      - currently when user was paused in blackboxed code (e.g. on breakpoint) and then makes step action, debugger ignores blackboxed state of the script and allows to use step actions as usual - this behavior is regressed, we still able to support it on frontend side.
      
      Current state and proposed changes for blackboxing: https://docs.google.com/document/d/1hnzaXPAN8_QC5ENxIgxgMNDbXLraM_OXT73rAyijTF8/edit?usp=sharing
      
      BUG=v8:5842
      R=yangguo@chromium.org,dgozman@chromium.org,alph@chromium.org
      
      Review-Url: https://codereview.chromium.org/2633803002
      Cr-Commit-Position: refs/heads/master@{#42614}
      ac50c79a
  27. 18 Jan, 2017 3 commits
  28. 13 Jan, 2017 1 commit
  29. 10 Jan, 2017 1 commit