AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
2999cea522
v8/test/inspector/debugger/doesnt-step-into-injected-script-expected.txt

18 lines
394 B
Plaintext
Raw Normal View History

[inspector] added inspector test runner [part 5] - added most part of inspector tests that depends only on JavaScript domains. BUG=chromium:635948 R=dgozman@chromium.org,alph@chromium.org Committed: https://crrev.com/9ddbdab195923fc87fae3587ae06c5c1c5ca6d79 Review-Url: https://codereview.chromium.org/2369753004 Cr-Original-Commit-Position: refs/heads/master@{#39897} Cr-Commit-Position: refs/heads/master@{#39931}
2016-10-02 21:22:49 +00:00
Check that stepInto at then end of the script go to next user script instead InjectedScriptSource.js.
[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
paused at:
(function boo() { setTimeout(() => 239, 0); #debugger; })()
paused at:
(function boo() { setTimeout(() => 239, 0); debugger; #})()
paused at:
Reland "[inspector] fixed location of top level function return" This is a reland of 4363a693352e75a919cf4524d1b3b17b204571c0 Original change's description: > [inspector] fixed location of top level function return > > We should pass false as has_braces argument to create FunctionLiteral > for top level function. > > R=dgozman@chromium.org,bmeurer@chromium.org > TBR=bmeurer@chromium.org > > Bug: none > Change-Id: I397f31b562d32c71f3a12bfc9ceeed16c367aa80 > Reviewed-on: https://chromium-review.googlesource.com/1098018 > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> > Reviewed-by: Dmitry Gozman <dgozman@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53769} TBR=dgozman@chromium.org Bug: v8:7858 Change-Id: Ie636bc101f9d29d9d40bd10b96e62da6505c2734 Reviewed-on: https://chromium-review.googlesource.com/1104497 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Cr-Commit-Position: refs/heads/master@{#53808}
2018-06-12 21:57:52 +00:00
(function boo() { setTimeout(() => 239, 0); debugger; })()
#
[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
paused at:
(function boo() { setTimeout(() => #239, 0); debugger; })()
Reference in New Issue Copy Permalink