Breakpoints are not resolved (they appear greyed in the editor) until just before they are executed

[hasimyerlikaya]

Describe the bug
I have a Dart API project, and I can't create breakpoints after updating to v3.72.2. There is no issue with v3.70.0.

Expected behavior
Be able to create breakpoint

Screenshots

• Operating System and version: macOS Ventura Version 13.5.2 (22G91)
• VS Code version: 1.82.0
• Dart extension version: v3.72.2
• Dart/Flutter SDK version: Dart 3.1.1 / Flutter 3.13.3

!! PLEASE REVIEW THIS LOG FOR SENSITIVE INFORMATION BEFORE SHARING !!

Dart Code extension: 3.72.2
Flutter extension: 3.72.0 (activated)

App: Visual Studio Code
App Host: desktop
Version: 1.82.0
Platform: mac

Workspace type: Dart
Analyzer type: LSP
Multi-root?: true

Dart SDK:
    Loc: /Users/hasimyerlikaya/flutter/bin/cache/dart-sdk
    Ver: 3.1.1
Flutter SDK:
    Loc: /Users/hasimyerlikaya/flutter
    Ver: 3.13.3

HTTP_PROXY: undefined
NO_PROXY: undefined

Logging Categories:
    General, AnalyzerTiming, CommandProcesses, DartTest, DAP, VmService, DevTools, FlutterDaemon, FlutterRun, FlutterTest, WebDaemon

Mon Sep 11 2023 [03:18:25 GMT+0300 (GMT+03:00)] Log file started
[3:18:28 AM] [DAP] [Info] ==> {"command":"setBreakpoints","arguments":{"source":{"name":"login_service.dart","path":"/lib/api/user/services/login_service.dart"},"lines":[19],"breakpoints":[{"line":19}],"sourceModified":false},"type":"request","seq":20}
[3:18:28 AM] [DAP] [Info] <== {"seq":30,"type":"response","body":{"breakpoints":[{"id":100007,"verified":false}]},"command":"setBreakpoints","request_seq":20,"success":true}
Mon Sep 11 2023 [03:18:33 GMT+0300 (GMT+03:00)] Log file ended

[DanTup]

@hasimyerlikaya the breakpoints now appear grey while they are "unresolved" (that is, the VM has not confirmed their locations). They should still work fine and turn red once the VM loads the source and verifies the location (this is usually just before the code executes).

Can you confirm that the breakpoints turn red and function once you actually trigger that code?

[hasimyerlikaya]

@DanTup Thank you for reply.

It is working perfectly, but when I see that it is not red, I think it won't work. In the previous version, it was red all the time. Now, I need to trigger it to ensure that there is no problem with debugging. As you know, when we start a Flutter project in release mode, break points won't be red. In my opinion, the break points should always be red in the dart project, like in the previous version. This version makes me feel that there is an error.

break.mp4

[DanTup]

Thanks for the feedback. I understand that this can be confusing when it worked differently for so long - but this new way does also help understand when breakpoints may be moved by the VM (for example if you put a breakpoint in an invalid location, when it turns red it when it will snap to the nearest location).

I think we may be able to add tooltip text to the grey breakpoints, so perhaps it would be clearer if there was a tooltip that said something like "The location of this breakpoint is not yet resolved" so it's clear it's not an error state?

@jacob314 @bkonyi also interested in your thoughts on this. The VM definitely resolves these locations more lazily then I would've expected, so in most cases the breakpoints are essentially "unresolved until this code executes for the first time" which makes the distinction a little less useful. I presume there's nothing we can do to encourage the VM to resolve these more eagerly?

[hasimyerlikaya]

@DanTup You are welcome.

Tooltip will help more. At least we can know that there is no problem. My preference would be a solid gray icon. That way it would be clearer that we are on standby.

[DanTup]

We can't change the icon color ourselves, that's handled by VS Code. However I've added some comments to microsoft/debug-adapter-protocol#425 (where I've asked about the semantics of "unverified" breakpoints before) to see whether maybe the debug protocol could support separate states for "failed to verify" and "not yet verified".

[snipd-min]

Hi @DanTup, thanks for the explanation!

I have to say somehow this behaviour feels really awkward for me... It's probably because I'm very used to having the breakpoint as "red" all the time as it's much easier to see where they are and only showing the red breakpoint when a loaded location is invalid (e.g. source file changed and the loaded location weren't in sync) feels more natural.

I totally get that this is the "intended" behaviour as the locations are lazily loaded but in practice it feels quite awkward... It seems unnecessary to show it as unverified unless the source file was modified and the changes are not yet synced to the dart server...

This is especially when "launching a debug session", as all source files will be saved automatically, won't all breakpoints of the program's source files be in theory "verified" even though their exact locations are not loaded?

[DanTup]

Yep, I understand - what's why I brought this up in the DAP issue above.

I don't think just reverting this behaviour is good, because it loses something - right now the greyed out breakpoints indicate their location is not resolved. That is, you cannot trust they will be hit in this location when they are hit. I think this is useful information (because I've had questions about breakpoints not being hit when they've been added to invalid locations before).

I've pinged on the issue above again and will see if any progress can be made there.

[dedvalson]

I don't think that what I am seeing matches the expected behavior above. Here is what I did:

1. Create new application using Flutter: new project.
2. Put a breakpoint in it. It shows up as orange.
3. Start debugging using F5 (Windows and Android Emulator).
4. The breakpoint changes to a white circle, then goes back to an orange dot once the app is running.
5. Hit the breakpoint, it works properly. It remains orange
6. Add a second breakpoint. Both breakpoints now turn into white circles.
7. Now, no matter what I do I never see an orange dot again until I stop debugging.

Any change in breakpoints made after the app starts running causes all breakpoints to change to white circles until debugging ends.

[bkonyi]

Sorry for the delayed response, I'm just catching up on emails now.

@jacob314 @bkonyi also interested in your thoughts on this. The VM definitely resolves these locations more lazily then I would've expected, so in most cases the breakpoints are essentially "unresolved until this code executes for the first time" which makes the distinction a little less useful. I presume there's nothing we can do to encourage the VM to resolve these more eagerly?

I think we might be able to trigger a compilation of unexecuted code when setting a breakpoint, which should result in a resolved breakpoint being returned. I can't say with certainty that we don't trigger a compilation of unexecuted code when setting a breakpoint already, so I'll have to look into this.

[DanTup]

@dedvalson

I don't think that what I am seeing matches the expected behavior above. Here is what I did:
...
Add a second breakpoint. Both breakpoints now turn into white circles.

Thanks for the clarification. This sounds like another bug #4469 that was expected to have been fixed. Can you confirm the version of the Flutter SDK and which platform you're seeing this on, and if possible provide exact steps to reproduce (including exactly which line(s) you're adding breakpoints to)?

Thanks!

@bkonyi

I think we might be able to trigger a compilation of unexecuted code when setting a breakpoint, which should result in a resolved breakpoint being returned. I can't say with certainty that we don't trigger a compilation of unexecuted code when setting a breakpoint already, so I'll have to look into this.

Ah, that sounds like it would be perfect. If you think it should already be happening and need some steps to repro this issue, let me know.

[dedvalson]

Steps to reproduce:

1. Create a new Flutter application.
2. Place a breakpoint on line 67 ( _counter++;) The breakpoint is red.
3. Press F5 to start debugging. Breakpoint changes to white circle while compiling / launching.
4. Once app is running breakpoint turns red again.
5. Press the "+" floating action button in the app. The breakpoint is hit and stays red.
6. Press F5 again to resume running.
7. Place a breakpoint on line 79 (return Scaffold). Both breakpoints change to white circles.
8. Press the "+" button again.
9. The line 67 breakpoint is hit. Both breakpoints remain as white circles.
10. Press F5 to continue running.
11. The line 79 breakpoint is hit. Both breakpoints remain as white circles.

I am running DartCode 3.72.2

Here is the output of flutter doctor -v

[√] Flutter (Channel stable, 3.13.4, on Microsoft Windows [Version 10.0.19045.3324], locale en-US)
    • Flutter version 3.13.4 on channel stable at c:\Src\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 367f9ea16b (5 days ago), 2023-09-12 23:27:53 -0500
    • Engine revision 9064459a8b
    • Dart version 3.1.2
    • DevTools version 2.25.0

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
    • Android SDK at C:\Users\Don\AppData\Local\Android\sdk
    • Platform android-33, build-tools 30.0.3
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop Windows apps (Visual Studio Community 2019 16.6.2)
    • Visual Studio at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community
    • Visual Studio Community 2019 version 16.6.30204.135
    • Windows 10 SDK version 10.0.18362.0

[√] Android Studio (version 2022.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)

[√] IntelliJ IDEA Community Edition (version 2018.3)
    • IntelliJ at C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2018.3.3
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin version 183.5153.38

[√] VS Code (version 1.82.2)
    • VS Code at C:\Users\Don\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.34.0

[√] Connected device (4 available)
    • Android SDK built for x86 (mobile) • emulator-5554 • android-x86    • Android 10 (API 29) (emulator)
    • Windows (desktop)                  • windows       • windows-x64    • Microsoft Windows [Version 10.0.19045.3324]
    • Chrome (web)                       • chrome        • web-javascript • Google Chrome 116.0.5845.180
    • Edge (web)                         • edge          • web-javascript • Microsoft Edge 113.0.1774.42

[√] Network resources
    • All expected network resources are available.

• No issues found!

Here is the output from VSCode About

Version: 1.82.2 (user setup)
Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d
Date: 2023-09-14T05:55:25.390Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.19045

The Target is an Android Simulator running API 29.

I see exactly the same symptoms when the target is a native Windows application.