v8/test/inspector/debugger/step-into-next-script-expected.txt

72 lines
989 B
Plaintext
Raw Normal View History

Debugger breaks in next script after stepOut from previous one.
Running test: testStepOut
test (foo.js:12:2)
(anonymous) (:0:0)
(anonymous) (:0:6)
[inspector] changed a way of preserving stepping between tasks 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}
2017-03-22 16:20:54 +00:00
(anonymous) (timeout1.js:0:8)
[inspector] changed a way of preserving stepping between tasks 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}
2017-03-22 16:20:54 +00:00
foo (timeout2.js:2:2)
[inspector] changed a way of preserving stepping between tasks 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}
2017-03-22 16:20:54 +00:00
(anonymous) (timeout3.js:0:8)
Running test: testStepOver
(anonymous) (:0:0)
test (foo.js:12:2)
(anonymous) (:0:0)
test (foo.js:13:0)
(anonymous) (:0:0)
(anonymous) (:0:6)
(anonymous) (timeout1.js:0:8)
(anonymous) (timeout1.js:0:35)
foo (timeout2.js:2:2)
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
foo (timeout2.js:2:12)
(anonymous) (timeout3.js:0:8)
(anonymous) (timeout3.js:0:35)
Running test: testStepInto
(anonymous) (:0:0)
test (foo.js:9:2)
(anonymous) (:0:0)
test (foo.js:10:2)
(anonymous) (:0:0)
test (foo.js:11:2)
(anonymous) (:0:0)
test (foo.js:12:2)
(anonymous) (:0:0)
test (foo.js:13:0)
(anonymous) (:0:0)
(anonymous) (:0:6)
(anonymous) (timeout1.js:0:8)
(anonymous) (timeout1.js:0:35)
foo (timeout2.js:2:2)
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
foo (timeout2.js:2:12)
(anonymous) (timeout3.js:0:8)
(anonymous) (timeout3.js:0:35)