Repository navigation
Warn users when there are breakpoints on SDK/Packages that won't be hit due to debug settings #2428
Description
Seen result:
I can place breakpoints inside of my unit test and execution will pause correctly, but if I put a breakpoint in the framework, say packages/flutter/lib/src/widgets/scroll_physics.dart the breakpoint will not trigger.
Expected result:
I expect breakpoints in the framework to behave like breakpoints in the unit tests.
Seen system:
Dart Code Version: 3.10.1
VSCode: 1.44.2
Operating System: Mac OS X 10.14.6
Flutter Doctor:
[✓] Flutter (Channel unknown, 1.18.0-9.0.pre.66, on Mac OS X 10.14.6 18G2022, locale en-US)
• Flutter version 1.18.0-9.0.pre.66 at /Users/aaclarke/dev/flutter
• Framework revision 780d93bf38 (19 hours ago), 2020-05-04 17:18:41 -0700
• Engine revision 4bcfae82c7
• Dart version 2.9.0 (build 2.9.0-3.0.dev a69cb6d700)
Notes:
- If I use the
debugger()function in my desired code, execution will pause but the stack trace inside of visual studio code will not include anything beyond the unit test.
Activity
gaaclarke commentedon May 5, 2020
I was able to get the breakpoints to work by adding the following settings:
Debug Sdk LibrariesDebug External LibrariesOnly doing
Debug Sdk Librarieswasn't sufficient, I had to do both. I'm not sure what the benefit there is to turning these off. Seems like it should be on by default, or at least pop up a dialog if someone adds a breakpoint that won't be triggered.DanTup commentedon May 6, 2020
This is expected, SDK here refers to the Dart SDK and built-in
dart:libraries, where as Flutter is considered a package (package:flutter). I'll tweak the text on the descriptions for these settings to make that clearer.When this setting was added, we prompted users at startup to ask which they'd rather have. Most people picked to debug "just my code" and eventually the prompt was removed (it's weird to pop up and ask about one specific setting when there are so many).
With this off, ehen an exception occurs in the framework, it will break the debugger where your code called into the framework. For example, if you have an
assertthat fails, you may consider it more useful to break in your code where theassertcall is than deep inside the implementation of theassert.To improve visibility and to make it easier to switch while debugging, v3.7 added a status bar toggle for quickly switching between these:
https://dartcode.org/releases/v3-7/#debug-mode-toggle
Hope this helps!
Tweak settings text for #2428
[-]Unable to break on breakpoints in the framework[/-][+]Warn users when there are breakpoints on SDK/Packages that won't be hit due to debug settings[/+]DanTup commentedon May 6, 2020
This might be possible, I'll take a look - thanks!
gaaclarke commentedon May 6, 2020
Makes sense, thanks @DanTup. Also, in lieu of a warning we could consider just treating explicit breakpoints as exceptions to the settings, too. That might be easier. I think it's a pretty clear signal someone wants it to break there if they go through the trouble of adding the breakpoint.
DanTup commentedon May 18, 2020
I'd prefer to prompt the user rather than silently change it, since it affects more than just breakpoints (otherwise we could just default it to on).
It's a bit more complicated than I expected though, as we usually look at the libraries URI to decide if a library is SDK/package, but when breakpoints are set we only have file paths (that is, if you F12 into an SDK library, you'll put the breakpoint in the full path to the SDK, but when we're setting which libraries are debuggable, we're looking for
dart:libraries).I'll think more about this and see what I can come up with.
gaaclarke commentedon May 18, 2020
Thanks @DanTup, you won't need to change the value, just redefine what it means. The definition is the same except for this one addition "explicitly set breakpoints always break no matter where they are set". Given the information you have, that seems possible.
DanTup commentedon May 19, 2020
That's unfortunately not possible. We don't control the breaking or stepping behaviour, it's all in the VM. All we get to do is (at startup) tell the VM "please enable debugging for these [...] libraries". This will have the effect of both preventing stepping into them and having breakpoints not work.
Therefore my plan is that while we're passing the breakpoints to the VM, we check whether they're user-code/SDK/external-package and if they are, but those settings are not enabled, we prompt the user to change their settings. This however, requires resolving the file paths to one of those categories.
I have some possible ideas, but I don't know how feasible they are, I need to do a little more testing. At its most basic, we could probably just detect if a breakpoint it outside of the open workspace at all, and assume that's likely either the SDK or a pub package, and show the prompt.
DanTup commentedon May 19, 2020
Neither of my other ideas worked, so the best I could come up with for now is this when you have a breakpoint outside of your current workspace. If you already have them, this will appear at project open, but otherwise it'll appear as soon as you add the breakpoint:
It will only prompt once per session (and if you click Never Ask it won't ask again).
Prompt to change debug settings if breakpoints outside workspace
Prompt to change debug settings if breakpoints outside workspace