Popup "Validating breakpoint location..." waits rather long when removing a breakpoint

[abelbraaksma]

The following screen pops up when removing a breakpoint (the message is a bit confusing, I'd assume that validating a breakpoint location is something you need to do when setting a breakpoint):

The issue is not with the message, which is informative to some extend, but with it lingering around for sometimes extended periods of time (from seconds to over half a minute).

Repro steps

With F9 when removing an existing breakpoint. Happens occasionally, but more often when the project has been open longer. Not seen in small projects.

After it happens once for a certain line, it doesn't happen again when hitting F9 several times.

Expected behavior

Either no popup or very briefly.

Actual behavior

Popup can stay for as long as half a minute (possibly longer, but debugging becomes impossible at that point, so I restart).

Known workarounds

Restart Visual Studio. The behavior comes back only after a while.

Related information

Seen on:

• Visual Studio 2017, Preview 6.
• Windows 7, latest service packs
• F# 4.4.0.0 and F# 4.4.1.0 projects

[forki]

Yes this happens since vs 2017 release. It's very unfortunate and I try to debug it at least at 3 different occasions. But I didn't find anything interesting.

[KevinRansom]

Yes this is super irritating and something that needs to be looked at. I think the bug is actually in VS rather than our code. I'm not sure when I will be able to dig in to it. There is still a bunch of other stuff to do.

I am sorry I don't have a great answer.

[forki]

I also saw that VS is calling our breakpoint logic multiple times on one F9 press.

[KevinRansom]

Yes, however, the delay is enormous, I think there are more fundamental reasons in the debugger for it.

[dsyme]

@abelbraaksma Does pressing "cancel" dismiss the dialog?

[abelbraaksma]

@dsyme , interestingly, I haven't seen it in a while (now using VS2017 Preview 7), but I never dared to click Cancel as I expected even worse things to happen then ;).

I somewhat link this to the age old issue of Visual Studio becoming slow after several breakpoints have been set and cleared. The solution to that issue has always been to select "clear all breakpoints" (even if you have zero breakpoints left). I tried that here too but it seemed to have limited effect.

I know habitually erase all breakpoints, but perhaps I should allow the list to grow to see if the issue comes back (though in the original issue it happened after only a few breakpionts).

Sorry, not the most insightful information to narrow this down, I know...

[abelbraaksma]

@dsyme: forget my latest comment, yesterday night it happened several times in separate debugging sessions, so it is still happening. This was in VS2017 15.3.1.0. Just installed the nightly of today, will keep track whether it still happens.

[vasily-kirichenko]

@dsyme I believe the root cause of this issue is that ParseFileInProject is performed in the Reactor and we should finally pull it out of it. (breakpoint validation needs untyped AST only, doesn't it?)

[dsyme]

@dsyme I believe the root cause of this issue is that ParseFileInProject is performed in the Reactor and we should finally pull it out of it. (breakpoint validation needs untyped AST only, doesn't it?)

If that would solve it, that would be great

Equally, the reactor should never be blocking so long....

[cartermp]

@vasily-kirichenko That does sound right. @dsyme what sorts of things would we have to watch out for if we moved it off the reactor thread? Just so that we avoid any catastrophic bug months down the line 😄

[dsyme]

@cartermp IIRC I don't know of any gotchas for that, there's a note in the code about it being possible

[abelbraaksma]

@vasily-kirichenko, out of curiosity, is this possibly the same cause for the sometimes 30 seconds or more delay when going to a declaration (F12)? That also pops up and waits rather long. But at other times it is fast in the same code, hard to find a consistent repro.