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

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

About this issue

Original URL
State: open
Created 10 months ago
Reactions: 18
Comments: 30 (14 by maintainers)

Most upvoted comments

@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.

https://github.com/Dart-Code/Dart-Code/assets/7986394/ab77be42-5358-45d5-940a-f082e5f301b5

hasimyerlikaya on Sep 11, 2023

We can’t change the icon color ourselves, that’s handled by VS Code. However I’ve added some comments to https://github.com/microsoft/debug-adapter-protocol/issues/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”.

DanTup on Sep 11, 2023

This is definitely a regression, for me it’s almost unusable:

Breakpoints don’t appear where I add them
they are not red
they work when executing code though

It’s just a subpar experience compared to what it was before and wastes a lot of time where developing and creates a sense in the developer that they cannot trust the tooling.

intonarumori on Oct 4, 2023

One last question on this example though: why would I be able to set a verified breakpoint on the indicated line (136), while other lines below that, in the same function, could not be verified? That does not seem like expected behavior to me, unless a line contains no actual code.

I’m not 100% sure, but my guess is that it’s because you’re setting a breakpoint in a closure defined within the widget instantiation. This closure is a separate function from profileEndorsements so, with the current behaviour, the breakpoint will only be resolved once the closure on line 140 executes.

bkonyi on Oct 18, 2023

Here’s an unusual case I found – I can set a breakpoint successfully on line 136, and the debugger will stop on that line, but if I try to set a breakpoint on any of the nested lines below line 136, the breakpoint shows as unverified, and the debugger never stops on the line.

This used to work fine before the breakpoint system was changed; now it’s broken. In other words, this is not just a breakpoint rendering issue – the breakpoints simply don’t work anymore under some circumstances.

lukehutch on Oct 18, 2023

(@bkonyi I saw the issue you were blocked on was fixed… hopefully this means you can land your fix now too - let me know if you’d like me to do any testing of the changes)

There’s still some test failures I need to resolve, but hopefully I can find some time this week to figure out the last couple of issues. Eagerly compiling code before setting breakpoints has uncovered a bunch of minor bugs that were hidden due to breakpoints being set in uncompiled functions most of the time.

bkonyi on Oct 16, 2023

Sure, I will double check my setup and file an issue.

Thanks!

Most other dev tools like Xcode and Android Studio use filled / unfilled circle to signal if the breakpoint is enabled, not if it’s resolved, so I’d argue we are going against the grain here.

The UI here is controlled by VS Code - the grey circles are how unverified breakpoints are rendered by VS Code. It’s a bug that the breakpoints are verifying late (and @bkonyi has started a fix for this), but if the visuals of unverified vs disabled breakpoints seems bad, that would need to be filed https://github.com/microsoft/vscode.

DanTup on Oct 4, 2023

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

Create new application using Flutter: new project.
Put a breakpoint in it. It shows up as orange.
Start debugging using F5 (Windows and Android Emulator).
The breakpoint changes to a white circle, then goes back to an orange dot once the app is running.
Hit the breakpoint, it works properly. It remains orange
Add a second breakpoint. Both breakpoints now turn into white circles.
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.

dedvalson on Sep 18, 2023