Fsharp: 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.

[vasily-kirichenko]

@abelbraaksma unfortunately, no. Go to declaration does need file type check results, so the delay is unavoidable.

[cartermp]

@abelbraaksma This should be fixed with #3601. Can you verify this?

[abelbraaksma]

I'll be on a holiday in two days, but I'll try to squeeze it in before that.

[Tbd19]

I am having the similar problem with the popup but when I try to run the application. The enviroment is version 15.6.7

[cartermp]

@Tbd19 when you say "when I try to run the application", what are you referring to?

[abelbraaksma]

This should be fixed with #3601. Can you verify this?

Sorry for not getting back at it, it's sometimes quite difficult to track "open" issues as there's only one state for everything: open or closed. Maybe we should use something like assignment?

Either way, I have not seen this happening in a long time and I've used debugging and setting/removing breakpoints almost daily, so I think we can close this now, @cartermp?

@Tbd19, maybe you can create a separate issue with a repro for your situation? It may or may not be related, but you can link to this issue by mentioning it.

[cartermp]

I'll close this for now. @Tbd19 if you have a reproducible scenario, please do report back.

[FVivolo]

I still have this issue, hope not to bring this from the death, using VS2017, still don't understand what does MS need to fix this issue, very annoying and easily to reproduce just open a UWP which use javascript and each time you want to put/set a breakpoint you spend time pressing cancel like 4 time for each one you set and every time you start the application. version 15.9.7

[cartermp]

@FVivolo Unfortunately this issue was specific to the F# tools, not a general VS thing. If you are seeing this with UWP JavaScript, then I suggest using the Report a Problem tool in VS. That being said, VS 2019 is where bug fixes of this variety would get included. VS 2017 is now in long-term servicing mode and will only get servicing updates for security and high-priority bug fixes until it goes out of service.