Skip to content

V
V8
Switch branch/tag
  1. 24 Mar, 2017 1 commit
  3. 22 Mar, 2017 4 commits
    • kozyatinskiy's avatar
      [inspector] follow up for e27d18c9 · 69ad35ac
      kozyatinskiy authored 
      - renamed inspector-test methods,
- tuned comment in debug.h

BUG=v8:6118
TBR=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2766283002
Cr-Commit-Position: refs/heads/master@{#44043}
      69ad35ac
    • kozyatinskiy's avatar
      [inspector] added flag for injected-script-source debugging · 5f8c0a13
      kozyatinskiy authored 
      With flag we can debug injected-script-source in inspector-test or from DevTools frontend as regular user code. We need this when working on new features or debugging issues, it's for internal purpose only and doesn't provide any benefits for end users.

Flag: --expose-inspector-scripts

BUG=none
R=yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2767873002
Cr-Commit-Position: refs/heads/master@{#44039}
      5f8c0a13
    • 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
    • kozyatinskiy's avatar
      [debugger] tuned StepNext and StepOut at return position · e27d18c9
      kozyatinskiy authored 
      Proposed behaviour:
- StepNext at return position go into next function call (no changes with current behavior, but implemented in v8::Debug instead of hack on inspector side);
- StepOut at return position go into next non-current function call.

We need this to have better stepping in cases with native functions, blackboxed functions and/or different embedder calls (e.g. event listeners).

New behavior could be illustrated with two examples (for more see stepping-with-natives-and-frameworks test):
- let's assume that we've blackboxed callAll function, this function just takes its arguments and call one after another:
var foo = () => 1;
callAll(foo, foo, () => 2);
If we break inside of first call of function foo. Then on..
..StepNext - we're able to reach second call of function foo,
..StepOut - we're able to reach () => 2 call.

- let's consider case with native function:
[1,2,3].map(x => x * 2)
If we break inside of first callback call, then with StepNext we can iterate through all calls of callback, with StepOut we go to next statement after .map call.

Implementation details:
- when we request break we schedule step-in function call for any step action at return position and for step-in at any position,
- when we request StepOut at return position - we mark current function as needed-to-be-ignored inside of PrepareStepIn(function) call,
- when we request StepOut at not return position - we set break at return position and ask debugger to just repeat last step action on next stepping-related break.

Design doc: https://docs.google.com/document/d/1ihXHOIhP_q-fJCA0e2EiXz_Zr3B08KMjaPifcaqZ60Q/edit

BUG=v8:6118,chromium:583193
R=dgozman@chromium.org,yangguo@chromium.org

Review-Url: https://codereview.chromium.org/2758483002
Cr-Commit-Position: refs/heads/master@{#44028}
      e27d18c9
  5. 16 Mar, 2017 1 commit
  7. 14 Mar, 2017 2 commits
  9. 13 Mar, 2017 2 commits
  11. 10 Mar, 2017 1 commit
  13. 07 Mar, 2017 3 commits
  15. 06 Mar, 2017 2 commits
  17. 03 Mar, 2017 2 commits
  19. 02 Mar, 2017 1 commit
  21. 28 Feb, 2017 2 commits
  23. 27 Feb, 2017 3 commits
  25. 24 Feb, 2017 1 commit
  27. 23 Feb, 2017 2 commits
  29. 10 Feb, 2017 1 commit
  31. 09 Feb, 2017 1 commit
  33. 08 Feb, 2017 1 commit
    • kozyatinskiy's avatar
      [inspector] support for nested scheduled breaks · 56bf7dbd
      kozyatinskiy authored 
      In current implementation we don't support nested scheduled break at all. If one break was scheduled inside another and second one doesn't produce actual break (execution was in blackboxed code or no JavaScript was executed) then second one will clear first scheduled break even if any not blackboxed JavaScript will be executed later.

Ambiguous break reason is added for the case when we have more then one scheduled reason. "auxData" in this case contains object with array of { reason: reason, auxData: auxData } objects for each reason in 'reasons' property.

BUG=chromium:632405

Review-Url: https://codereview.chromium.org/2678313002
Cr-Commit-Position: refs/heads/master@{#43021}
      56bf7dbd
  35. 07 Feb, 2017 1 commit
  37. 03 Feb, 2017 3 commits
  39. 31 Jan, 2017 1 commit
  41. 27 Jan, 2017 3 commits
  43. 26 Jan, 2017 2 commits