Unable to set breakpoints in parts of a library

[bergwerf]

I know this sounds dramatic, but somehow it seems to be the case.
Dart version 1.25.0-dev.1.0, downgrading to 1.24.1-1 fixed the issue. I use Dart debugging with VS code, not sure how to reproduce it on the command line. Can be reproduced with https://github.com/hermanbergwerf/euclid by setting a breakpoint at https://github.com/hermanbergwerf/euclid/blob/e12b0cae7af7482ef56da9b971ff2bcaf8f6a63c/lib/src/algorithms/conics_intersection.dart#L37.

[rmacnak-google]

return result.map((v) => v.xy / v.z).toList();

This line has code that is in intersectConics and code in the anonymous closure. If the breakpoint is resolved a position in the anonymous closure, then the debugger won't pause on that line when the code in intersectConics runs.

I think @sivachandra made changes recently to how breakpoints are resolved, which might explain a difference in behavior between 1.24 and 1.25.

The deeper issue here is line-based breakpoint are ambiguous, and VS should be using precise source locations.

[bergwerf]

Right. I don't know how this is implemented, or how it should be implemented. But I guess this means https://github.com/Dart-Code/Dart-Code (Dart plugin for VS code) must be patched. I opened an issue there: Dart-Code/Dart-Code#334.

[DanTup]

The deeper issue here is line-based breakpoint are ambiguous, and VS should be using precise source locations.

I've got a case open to support this; I don't think it was originally supported by Code:

Dart-Code/Dart-Code#260

If the breakpoint is resolved a position in the anonymous closure, then the debugger won't pause on that line when the code in intersectConics runs.

I'm slightly confused by this - where the debugger resolves the breakpoint to and chooses to stop is surely out of my (Dart Code's) hands? If I'm not currently providing a column number for the breakpoint I would expect it to resolve to the start of the line, but even if it resolved inside the anonymous function surely the debugger would break on that line in either case? (unless of course the function never executes, but looking at the code it doesn't seem like that's a possibility)?

[DanTup]

I don't believe this is related to column numbers, because in the repro @hermanbergwerf provided in Dart-Code/Dart-Code#334 the breakpoint is on a line that looks like this:

  print('Break!');

Here's my notes and repro from Dart-Code/Dart-Code#334. If this isn't a bug in 1.25 then I'll need some info on what I'm doing wrong and how I can fix it.

---

Ok, I ran this same test in 1.24 and 1.25 and found this..

We currently send breakpoints twice because we previously found that depending on how a file was imported, the debugger would not break on it (some discussion in Dart-Code/Dart-Code#134). So the request to add breakpoints looks like this:

==> {"id":"5","method":"addBreakpointWithScriptUri","params":{"isolateId":"isolates/11111111","scriptUri":"file:///c:/Users/danny/Desktop/DartDebugSample/lib/src/test.dart","line":4}}
==> {"id":"6","method":"addBreakpointWithScriptUri","params":{"isolateId":"isolates/11111111","scriptUri":"package:yourpackage/src/test.dart","line":4}}

In 1.24, both of these breakpoints are accepted:

<== {"jsonrpc":"2.0", "result":{"type":"Breakpoint","fixedId":true,"id":"breakpoints\/1","breakpointNumber":1,"resolved":false,"location":{"type":"UnresolvedSourceLocation","scriptUri":"file:\/\/\/c:\/Users\/danny\/Desktop\/DartDebugSample\/lib\/src\/test.dart","line":4}},"id":"5"}
<== {"jsonrpc":"2.0", "result":{"type":"Breakpoint","fixedId":true,"id":"breakpoints\/2","breakpointNumber":2,"resolved":false,"location":{"type":"UnresolvedSourceLocation","script":{"type":"@Script","fixedId":true,"id":"libraries\/@17134453\/scripts\/package%3Ayourpackage%2Fsrc%2Ftest.dart\/15cd52126c7","uri":"package:yourpackage\/src\/test.dart","_kind":"source"},"line":4}},"id":"6"}

and when we go on to execute, we stop at the second breakpoint - the "package" version.

However, here's what happens in 1.25. We send the same requests:

==> {"id":"5","method":"addBreakpointWithScriptUri","params":{"isolateId":"isolates/11111111","scriptUri":"file:///c:/Users/danny/Desktop/DartDebugSample/lib/src/test.dart","line":4}}
==> {"id":"6","method":"addBreakpointWithScriptUri","params":{"isolateId":"isolates/11111111","scriptUri":"package:yourpackage/src/test.dart","line":4}}

But here's the response:

<== {"jsonrpc":"2.0", "result":{"type":"Breakpoint","fixedId":true,"id":"breakpoints\/1","breakpointNumber":1,"resolved":false,"location":{"type":"UnresolvedSourceLocation","scriptUri":"file:\/\/\/c:\/Users\/danny\/Desktop\/DartDebugSample\/lib\/src\/test.dart","line":4}},"id":"5"}
<== {"jsonrpc":"2.0", "error":{"code":102,"message":"Cannot add breakpoint","data":{"request":{"method":"addBreakpointWithScriptUri","params":{"isolateId":"isolates\/11111111","scriptUri":"package:yourpackage\/src\/test.dart","line":"4"}},"details":"addBreakpointWithScriptUri: Cannot add breakpoint at line '4'"}},"id":"6"}

Note that the second breakpoint (which is the one that breaks in 1.24) is the one being rejected.

So, I have no idea how to fix this - the breakpoint we can't set is the one that would actually work.

DartDebugSample.zip

[sivachandra]

I will review the different scenarios and see if we can do better here. If yes, will follow up with a fix as well.

[sivachandra]

I changed the title of this issue and have a change under review: https://codereview.chromium.org/2965673004/

[sivachandra]

@hermanbergwerf, @DanTup: The fix has landed. Could you test and see if the problem is fixed for you?

[DanTup]

By landed - do you mean it's in the latest dev release?

If so, I'll give it a test on Thursday when next working on Dart Code.

[sivachandra]

Ah, I thought you could use ToT. If not, you will have to wait for it to be picked up by a dev release.

[DanTup]

What's ToT?

I do hope to get set up so I can build the SDK stuff at some point; but it hasn't happened yet ;(

[sivachandra]

ToT == Top of Trunk
Anyway, 1.25.0-dev.6.0 has my change now.

[DanTup]

Breakpoint in the sample I had seems to work correctly in dev.6.0 for me!

[sivachandra]

Closing. If required, please reopen or file another bug as suitable.