Updated code so now we resolve pending breakpoints onScriptParsed instead onScriptPaused when using break on load #290

digeff · 2018-02-15T22:40:24Z

The general idea of this code change is that now all the pending breakpoints will get resolved onScriptParsed. Because we don't know in which order things will be executed, we'll have a defer used as a semaphore. The break-on-load logic inside onScriptPaused won't continue until the associated onScriptParsed has finished resolving all the pending breakpoints.

We need to make this change because of files that start with a function declaration, 0,0 is inside the function, so the break-on-load breakpoint is sometimes never hit, so then even after we refresh the page, no breakpoints are hit in that file because they are all still pending.

Is there a better way to solve this issue?

Some specific question:
I had to remove: "&& !pendingBP.bpsSet?" from line 697 to make this work. I'm not sure how that code was being used. It removing that code the right thing to do?
How should I handle the refresh case? Do we need to do anything special for that case? Should I call this._scriptIdToBreakpointsAreResolvedDefer.clear(); inside clearTargetContext?

roblourens · 2018-02-16T00:29:26Z

Is there no guarantee that a scriptParsed event will come before a pause event on that script? Have you ever seen them come in the wrong order or is it just being careful?

I had to remove: "&& !pendingBP.bpsSet?" from line 697 to make this work. I'm not sure how that code was being used. It removing that code the right thing to do?

That code is for the case where we set a BP and believe we have the correct sourcemapped location for it, but the script is not yet loaded. That exact check was added recently in c125224 and the bug was quite bad so the check should stay. But I suspect that when I fixed that, I actually broke something else which is what bpsSet was originally added for - the case when we think we have the correct location, but actually don't (so the pending BP still needs to be resolved) but I'll look at that later. Why did you have to remove it? I don't think your pending BPs should have that flag set.

How should I handle the refresh case? Do we need to do anything special for that case?

I'm not sure, what do you mean by "refresh case" exactly?

digeff · 2018-02-16T00:38:00Z

After discussing this with Dhanvi, we decided not to take this change.

digeff · 2018-02-20T17:19:28Z

@roblourens: After discussing this in more depth, we decided to merge this, although we are not sure if we want to merge it for this release, or the next one. Please help us get this into a state where it's ready to merge, and after we get to that state we'll decide whether to merge it in this release, or in the next release

digeff · 2018-02-20T17:35:11Z

Is there no guarantee that a scriptParsed event will come before a pause event on that script? Have you ever seen them come in the wrong order or is it just being careful? --> I'm assuming that you are asking why do we need this "waiting" logic. If that's the case, onScriptParsed and onScriptPaused do always arrive in the correct order. The issue is that we are not blocking the thread until all the work gets done. The resolved breakpoints are set in a non-blocking async manner, so it's possible that onScriptPaused executes while parts of onScriptParsed are still executing (in particular before we resolve all the breakpoints).

digeff · 2018-02-20T17:38:43Z

I'm not sure, what do you mean by "refresh case" exactly? --> I'm not sure whether we need some special logic on clearTargetContext or something like that. What happens if we navigate or we refresh while we are in the middle of resolving breakpoints onScriptParsed and we navigate to the same page, or a different page? Can we have two onScriptParsed handlers for the same url been executed at the same time (one for before the refresh, one for after)? How do we handle things properly in that case?

digeff · 2018-02-20T19:22:24Z

@roblourens I've updated the PR to do something reasonable with bpSet, rather than just remove it :).

roblourens · 2018-02-22T16:31:53Z

src/chrome/breakOnLoadHelper.ts

        const anyBreakpointsAtPausedLocation = committedBps.filter(bp =>
            bp.actualLocation.lineNumber === pausedLocation.lineNumber && bp.actualLocation.columnNumber === pausedLocation.columnNumber).length > 0;

-        // If there were any pending breakpoints resolved and any of them was at (1,1) we shouldn't continue
-        if (anyPendingBreakpointsResolved && anyBreakpointsAtPausedLocation) {
+        // If there were any breakpoints at (1,1) we shouldn't continue


"at (1,1)" is this still accurate? It can be anywhere now?

// If there were any breakpoints at this location (Which generally should be (1,1)) we shouldn't continue

roblourens · 2018-02-22T16:32:59Z

src/chrome/chromeDebugAdapter.ts

-
-        if (script.url) {
-            script.url = utils.fixDriveLetter(script.url);
+    public breakpointsResolvedDefer(scriptId: string): PromiseDefer<void> {


What's the verb in this method name, should it be a "get..."?

getBreakpointsResolvedDefer

roblourens · 2018-02-22T16:34:09Z

src/chrome/chromeDebugAdapter.ts

+        try {
+            this.doAfterProcessingSourceEvents(async () => { // This will block future 'removed' source events, until this processing has been completed
+                if (typeof this._columnBreakpointsEnabled === 'undefined') {
+                    await this.detectColumnBreakpointSupport(script.scriptId).then(async () => {


Don't mix async/await and promises when possible

if (typeof this._columnBreakpointsEnabled === 'undefined') { await this.detectColumnBreakpointSupport(script.scriptId); await this.sendInitializedEvent(); }

roblourens · 2018-02-22T16:35:50Z

src/chrome/chromeDebugAdapter.ts

@@ -1316,7 +1341,7 @@ export abstract class ChromeDebugAdapter implements IDebugAdapter {
        };
    }

-    private targetBreakpointResponsesToClientBreakpoints(url: string, responses: ISetBreakpointResult[], requestBps: DebugProtocol.SourceBreakpoint[], ids?: number[]): DebugProtocol.Breakpoint[] {
+    private targetBreakpointResponsesToClientBreakpoints(url: string, responses: ISetBreakpointResult[], requestBps: DebugProtocol.SourceBreakpoint[], ids?: number[]): BreakpointSetResult[] {


method name isn't accurate with this change

targetBreakpointResponsesToBreakpointSetResults

roblourens · 2018-02-22T16:41:27Z

src/chrome/chromeDebugAdapter.ts

+                    return undefined;
+                }
+
+                if (sources) {


When is this undefined?

This code was added for this: #106 in 1bf19e8 so I'm assuming that the scenario is:
"sourcemaps can't be resolved ahead of time, or don't exist on disk."

roblourens · 2018-02-22T16:46:08Z

src/chrome/chromeDebugAdapter.ts

                        if (body.breakpoints.every(bp => !bp.verified)) {
+                            // If all breakpoints are set, we mark them as set. If not, we mark them as un-set so they'll be set
+                            const areAllSet = setBpResultBody.breakpoints.every(setBpResult => setBpResult.isSet);


I think this changes the way it works - bpsSet was true if the bp was attempted to be set - not that it was bound. The check below response.breakpointId !== undefined is only true when the bp is bound.

My understanding was that Debugger.setBreakpointByUrl always returns the breakpointId if the parameters are valid even if the breakpoint is unbound, and it also returns the actualLocation if the breakpoint was bound.

Sorry, you're correct.

roblourens · 2018-02-22T16:50:25Z

I'm not sure refresh is an issue, because of doAfterProcessingSourceEvents and once pending breakpoints are resolved, they don't need to become pending again because once the script has been loaded once during the lifetime of the adapter, we have set the bp in the correct location.

This is a complicated change and I'm not sure I follow the whole thing. Take a look at the feedback and let's try to have a call about it in the next day or two.

digeff · 2018-02-22T18:17:03Z

I'm adding some more awaits because if not the second call to breakpointsAreResolvedDefer.resolve() might be called to early...

…tead onScriptPaused when using break on load

…lve() is called correctly

roblourens · 2018-02-22T23:50:27Z

Please add some integration tests for this too

roblourens · 2018-02-23T00:14:55Z

src/chrome/chromeDebugAdapter.ts

-                    return <DebugProtocol.Breakpoint>{
+                    // If we don't have an actualLocation nor a breakpointId this is a pseudo-breakpoint because we are using break-on-load
+                    // so we mark the breakpoint as not set, so i'll be set after we load the actual script that has the breakpoint
+                    return { isSet: response.breakpointId !== undefined, breakpoint: <DebugProtocol.Breakpoint>{


Nitpick, please format these like

{ isSet... breakpoint: { ... } }

as I didn't notice there was a second object there at first.

roblourens · 2018-02-23T00:18:48Z

src/chrome/chromeDebugAdapter.ts

+                    this._pendingBreakpointsByUrl.delete(source);
+                    breakpointsAreResolvedDefer.resolve();
+                } else {
+                    breakpointsAreResolvedDefer.resolve();


You can just pull these two out of the if/else

I didn't noticed that, thanks :)... It's actually a bug to do these here, so I'm removing both of them....

roblourens · 2018-02-23T00:20:10Z

Never mind about the call. I think this will be fine. If you are comfortable with this, go ahead and merge it.

roblourens · 2018-02-24T01:02:47Z

src/chrome/chromeDebugAdapter.ts

-        });
+            if (this._initialSourceMapsP) {
+                this._initialSourceMapsP = <Promise<any>>Promise.all([this._initialSourceMapsP, sourceMapsP]);
+                await sourceMapsP;


Should this always be awaited outside the if block? And why does it need to be?

You are right, it should be outside.

We want this so we don't call breakpointsAreResolvedDefer.resolve(); until this has finished for sure. If we call breakpointsAreResolvedDefer.resolve(); too early that will cause issues.

roblourens · 2018-02-24T01:03:34Z

Left one more comment but you should have permission to merge it, please do that when you think it's ready. Let me know if it doesn't work, I'll do it.

digeff · 2018-03-05T22:55:36Z

@roblourens Any more feedback?

vscodebot bot assigned roblourens Feb 15, 2018

digeff closed this Feb 16, 2018

digeff reopened this Feb 20, 2018

digeff force-pushed the fix_not_hitting_bps branch from c8d0f70 to f38ce75 Compare February 20, 2018 17:42

roblourens reviewed Feb 22, 2018

View reviewed changes

roblourens suggested changes Feb 22, 2018

View reviewed changes

Diego Geffner added 6 commits February 22, 2018 11:03

Updated code so now we resolve pending breakpoints onScriptParsed ins…

0b32d01

…tead onScriptPaused when using break on load

tslint

82cf615

Mark pseudo-breakpoints from break-on-load results as not set

967655a

Applied first part of feedback

83d1ef0

Adding some awaits to make sure that breakpointsAreResolvedDefer.reso…

7681a65

…lve() is called correctly

tstlint

022bb8a

digeff force-pushed the fix_not_hitting_bps branch from c1900ab to 022bb8a Compare February 22, 2018 19:09

roblourens suggested changes Feb 23, 2018

View reviewed changes

Applied feedback and fixed bug

041e525

roblourens reviewed Feb 24, 2018

View reviewed changes

Apply feedback

4bf5c71

roblourens merged commit f999465 into microsoft:master Mar 6, 2018

digeff deleted the fix_not_hitting_bps branch March 6, 2018 00:35

roblourens added this to the March 2018 milestone Apr 3, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Updated code so now we resolve pending breakpoints onScriptParsed instead onScriptPaused when using break on load #290

Updated code so now we resolve pending breakpoints onScriptParsed instead onScriptPaused when using break on load #290

digeff commented Feb 15, 2018

roblourens commented Feb 16, 2018

digeff commented Feb 16, 2018

digeff commented Feb 20, 2018

digeff commented Feb 20, 2018

digeff commented Feb 20, 2018

digeff commented Feb 20, 2018

roblourens Feb 22, 2018

digeff Feb 22, 2018

roblourens Feb 22, 2018 •

edited

Loading

digeff Feb 22, 2018

roblourens Feb 22, 2018

digeff Feb 22, 2018

roblourens Feb 22, 2018

digeff Feb 22, 2018

roblourens Feb 22, 2018

digeff Feb 22, 2018

roblourens Feb 22, 2018

digeff Feb 22, 2018

roblourens Feb 23, 2018

roblourens commented Feb 22, 2018

digeff commented Feb 22, 2018

roblourens commented Feb 22, 2018

roblourens Feb 23, 2018

digeff Feb 23, 2018

roblourens Feb 23, 2018

digeff Feb 23, 2018

roblourens commented Feb 23, 2018

roblourens Feb 24, 2018

digeff Mar 5, 2018

roblourens commented Feb 24, 2018

digeff commented Mar 5, 2018

Updated code so now we resolve pending breakpoints onScriptParsed instead onScriptPaused when using break on load #290

Updated code so now we resolve pending breakpoints onScriptParsed instead onScriptPaused when using break on load #290

Conversation

digeff commented Feb 15, 2018

roblourens commented Feb 16, 2018

digeff commented Feb 16, 2018

digeff commented Feb 20, 2018

digeff commented Feb 20, 2018

digeff commented Feb 20, 2018

digeff commented Feb 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roblourens Feb 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roblourens commented Feb 22, 2018

digeff commented Feb 22, 2018

roblourens commented Feb 22, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roblourens commented Feb 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

roblourens commented Feb 24, 2018

digeff commented Mar 5, 2018

roblourens Feb 22, 2018 •

edited

Loading