Breakpoints aren't hit inside "part" files

[DanTup]

Moving from Dart-Code/Dart-Code#1443

It seems if you include a file using part/part-of then breakpoints set inside it aren't hit (at least, those set by VS Code while the app is paused at startup).

Here's a repro:

pubspec.yaml

name:          breakpoint_test
version:       0.0.1

bin/main.dart

import 'package:breakpoint_test/all_scripts.dart';

void main() {
  func();
}

lib/all_scripts.dart

library foo;

part 'src/func.dart';

lib/src/func.dart

part of foo;

void func() {
  print("Breakpoints don't work here!");
}

If I move func directly into all_scripts then it works fine.

breakpoint_test.zip

---

Some info on what be the issue from @peter-ahe-google:

My guess it that there could be a flaw in how the VM maps fileUris to importUris (this is a concept from Kernel, let me know if I need to elaborate).

We only store a fileUri on func. So you have to translate that back to the importUri, and it is not sufficient to look at the enclosing library's importUri.

I think it would be more reliable to translate importUris to fileUris (that is, convert package-URIs to file-URIs), because the debug information is based on those.

[zichangg]

@DanTup Hi Danny, I failed to reproduce the bug with your files on Linux. I used observatory to set breakpoints at func.dart and it then hit the breakpoint if I continued running. The code is latest from master branch.
Breakpoint 1 resolved at func.dart:4:3
Paused at breakpoint 1 at func.dart:4:3
Do I need to reproduce with VS Code?

[arsen]

It is still happening for me with VS Code (v1.31.0)
Flutter extension version 2.22.3

[DanTup]

@zichangg Yah, the issue only seems to occur for the breakpoints that are sent at startup while the isolate is paused (PauseStart?). If I add breakpoints later via Observatory, they work fine.

It may also happen with IntelliJ, I'm not sure.

Assuming you have VS Code set up, you can capture a log while reproducing by running the Dart: Capture Logs command (from the VS Code command palette) and then tick just the Debugger (Observatory) category. Then once you've finished, click Stop Logging on the notification (note it may have collapsed into tje bell icon in the status bar). That will open a log of all the JSON to/from the VM service (I though I'd attached a log here, but apparently I did not).

Let me know if you have any trouble reproducing!

[zichangg]

@DanTup Have a great weekend!
A question for Uris format. VM sent out the Uris with absolute path. From addBreakpoint request, the Uri received is package:breakpoint_test/src/func.dart. This causes scripts matching failed. Why transform Uris to packages:.. from your side?

[DanTup]

@zichangg The breakpoints seem to be expected as package: URIs in all other cases. I think it used to be only the case for external packages, but I think since #33076 it's also required for the package being run too.

To be honest, this stuff isn't well documented and it's been a lot of trial and error (and bugs). It would be best if the formats for breakpoints could be explicitly documented to avoid confusion like this (this has come up before, because often there have been mismatches across platforms - for ex see #32500).

We used to send every breakpoint twice (once as package: and once as a path) but this really complicated supporting "resolving" breakpoints in VS Code (something I still haven't finished) because we end up with two VM breakpoints for one Code breakpoint so I removed it. I think it should be predictable what we should send to avoid this.

[zichangg]

Blocked on #36023.

[DanTup]

@jensjoha thanks for this! Though I just built the SDK locally and still don't seem to hit the breakpoint. Here's the project I'm testing with (breakpoint is on the line BREAK HERE, line 4 in part.dart):

part_breakpoint_repro.zip

I'm using this version of the SDK:

Dart VM version: 2.2.1-edge.58882ffdd49afdfb53c7be15361340bb64760fe4 (Wed Mar 20 09:39:33 2019 +0000) on "macos_x64"

And here's a log of the VM service chatter:

observatory.txt

Any ideas what's wrong?

[jensjoha]

Hmm... I think that's a VM bug (or VSCode somehow setting breakpoints too soon according to who knows what) --- if you add a breakpoint to the line in main, then, when it stops there, add the breakpoint to package:hello_world/part.dart:4 and continues, it does actually stop in the part file...

[DanTup]

From the logs it looks like the isolate was in the PauseStart state which I think is when we're expected to send breakpoints. Who would be best to advise if this is a VM or VS Code issue? (AFAIC though, there's no other opportunity for us to send breakpoints - we can't let the code start running before doing it, or there could be races).

[jensjoha]

Reverting a051696 seems to fix the issue so maybe @alexmarkov would be the person to ping here.

The issue seems to be that the top level class stuff is delayed, i.e. when you set the breakpoint that part is not known by the VM yet. A latent breakpoint is set, and I suppose that would be fine if Debugger::NotifyDoneLoading() was called at the right time, but it isn't.

A "funny" thing is that if you add, e.g. "class Foo {}" and the end of "part.dart", the breakpoint is set just fine because that class is created (and thus the VM gets to know about the part up front).

[DanTup]

With @zichangg's most recent change, this seems to be working as expect. Thanks both! 👍

[alexmarkov]

The fix caused incorrect type finalization and was reverted. We need to find another way of fixing this.

[DanTup]

If this isn't likely to happen soon, do you know if there's a workaround? I tried switching from package URIs to file URIs (based on the original comments here), though that didn't seem to help (thanks to @bkonyi fixes, it's likely VS Code will move over to always using file URIs instead of package URIs for breakpoints soon).