Attaching to running flutter process doesn't highlight source paused on

[t-animal]

Describe the bug
When starting a flutter project using flutter run outside of vscode and then attaching the debugger inside vscode by running >Debug: Attach to Flutter on Device and pasting the URI provided by flutter, it is possible to set a breakpoint in a file and the debugger also stops the app, but it doesn't give any information about the current state and doesn't highlight the line that's paused on. The problem only occurs if in vscode the flutter project is nested in subfolder. As setting the breakpoint and breaking on it works correctly, but from then on it's pretty useless, it's hard to figure out what's wrong.

To Reproduce
Steps to reproduce the behavior:

1. Create a flutter project in a subfolder of the current vscode workspace (mkdir -p flutter-test/src; code flutter-test; cd flutter-test/src; flutter create .)
2. Start the flutter app using the CLI on a connected (android) device (flutter run)
3. Attach to the running flutter app on the connected device
4. Set a breakpoint, ensure the corresponding code is executed
5. Locate call stack, notice it only says "unknown source"; check code, notice it doesn't highlight the current line when stepping;

Expected behavior
Either setting the breakpoint should fail with a meaningful error message or locating the source should work not only for setting the breakpoints but also for resolving the debugged code.

Screenshots

Versions (please complete the following information):

• VS Code Version: 1.63.2
  Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
  Date: 2022-01-19T16:00:00.869Z
  Electron: 13.6.7
  Chromium: 91.0.4472.164
  Node.js: 14.16.0
  V8: 9.1.269.40-electron.0
  OS: Linux x64 5.16.2-arch1-1
• Dart extension version: v3.34.0
• Dart/Flutter SDK version: Flutter (Channel stable, 2.5.3, on Arch Linux 5.16.2-arch1-1, locale en_US.UTF-8

[DanTup]

This is a known limitation right now. When we connect to the Flutter app we only get URIs like package:my_flutter_app/... and are unable to translate them to file system paths to know where the source code is. There's a new API to handle this, but we're only using it in the new debug adapters (which aren't quite finished yet).

As a workaround, if you have a launch configuration (in .vscode/launch.json) for attaching and set the cwd to the folder that contains the app (and then use F5/Run -> Start Debugging to start the attach process) then we'll use that to find the packages file ourselves that lets us perform the mapping:

.vscode/launch.json

{
	"version": "0.2.0",
	"configurations": [
		{
			"name": "attach",
			"request": "attach", // Attach instead of launching
			"type": "dart",
			"cwd": "src", // Folder of the app
			"vmServiceUri": "${command:dart.promptForVmService}" // Prompt for the VM Service URI
		},
	]
}

I'll keep this issue open to ensure this is not required when we switch to the new DAPs.

[t-animal]

Unfortunately the suggested workaround doesn't work in my case. It prints the following on its debug console:

Error connecting to the service protocol: failed to connect to http://127.0.0.1:36565/_wEVjjUwOlw=/
Exited (sigterm)

The configuration works if I leave out "cwd", but however I specify the cwd (relative, absolute...) it prints the above.

[DanTup]

Could you try running the Dart: capture Debugging Logs command before doing this, then reproduce the issue and provide the log?

You could also try setting this instead:

"packages": ".dart_tool/package_config.json"

although I suspect it may do the same thing.

[DanTup]

I've opened #3809 specifically for the new issue you're seeing - let's continue that there, and keep this one open for ensuring the original issue is resolved with the new DAP.

[t-animal]

I'll post this here, too, because it allows me to use the debugger as intended. Using this configuration as suggested by DanTup works for me:

{
      "name": "Flutter attach",
      "request": "attach", // Attach instead of launching
      "type": "dart",
      "packages": "src/.dart_tool/package_config.json",
      "vmServiceUri": "${command:dart.promptForVmService}" // Prompt for the VM Service URI
    },

[DanTup]

Ah, glad that works. I'm not sure why changing the working directory doesn't, but we can troubleshoot that in #3809. Ofc I'll also make sure in the new SDK DAPs neither of these workarounds are required before closing this.

[nmfisher]

I'm experiencing a similar issue with breakpoints not triggered in VS Code Remote Extensions and port forwarding.

The following is just for background/context information, I'm fairly sure the issue is confined to package/file:// resolution issues which I've detailed at the bottom of this comment.

__________________________________________________________
|                                                         |
|    Windows                                              |
|    - VS Code                                            |  
|    - Android emulator                                   |
-----------------------------------------------------------
    |                               ^                |
    |                               |                |
Remote SSH Extension                |              VM service port forward
    |                         adb port forward       |         
    |                               |                |
   V                                |                V
_________________________________________________________
|                                                        | 
|    Linux                                               |
|    - Flutter project/src files                         |
|    - Flutter binaries                                  |
|     - VS Code Dart Extension                           |
|     - adb client                                       |
----------------------------------------------------------

(it may be relevant that the Dart extension is installed both locally and remotely).

What works:

• launching the app from VS Code on the emulator, getting debug output etc
• launching the app from command line and setting/triggering breakpoints in Flutter DevTools debugger
• in VS Code, automatically pausing/navigating to the correct source line when an Exception is thrown
• in VS Code, automatically pausing when debugger() from dart:developer is invoked (though the line number in the source file might be slightly off).
• in VS Code, setting breakpoints in Flutter widget packages (e.g. I can set a breakpoint inside flutter/lib/src/widgets/text.dart, and VS Code will correctly pause/navigate to this source)

What doesn't work:

• in VS Code, setting a breakpoint in project code and automatically pausing/navigating when triggered.

Note that the breakpoints are definitely successfully set:

[9:48:43 pm] [DAP] [Info] ==> {"seq":2044,"type":"event","event":"dart.log","body":{"message":"<== {\"jsonrpc\":\"2.0\",\"method\":\"streamNotify\",\"params\":{\"streamId\":\"Debug\",\"event\":{\"type\":\"Event\",\"kind\":\"BreakpointAdded\",\"isolate\":{\"type\":\"@Isolate\",\"id\":\"isolates/797724818850851\",\"name\":\"main\",\"number\":\"797724818850851\",\"isSystemIsolate\":false},\"timestamp\":1648648119508,\"breakpoint\":{\"type\":\"Breakpoint\",\"fixedId\":true,\"id\":\"breakpoints/4\",\"enabled\":true,\"breakpointNumber\":4,\"resolved\":false,\"location\":{\"type\":\"UnresolvedSourceLocation\",\"scriptUri\":\"file:///home/hydroxide/projects/polyvox/flutter_onnx/example/lib/main.dart\",\"line\":55}}}}}\n","severity":0,"category":10}}

However, I can also see that the scriptUri reference uses file:/// references, whereas the (correctly functioning) Exceptions are referenced using package:... notation:

[10:07:48 pm] [DAP] [Info] ==> {"seq":2205,"type":"event","event":"dart.log","body":{"message":"<== {\"jsonrpc\":\"2.0\",\"method\":\"streamNotify\",\"params\":{\"streamId\":\"Debug\",\"event\":{\"type\":\"Event\",\"kind\":\"PauseException\",\"isolate\":{\"type\":\"@Isolate\",\"id\":\"isolates/797724818850851\",\"name\":\"main\",\"number\":\"797724818850851\",\"isSystemIsolate\":false},\"timestamp\":1648649265299,\"topFrame\":{\"type\":\"Frame\",\"kind\":\"Regular\",\"location\":{\"type\":\"SourceLocation\",\"script\":{\"type\":\"@Script\",\"fixedId\":true,\"id\":\"libraries/@564463603/scripts/package%3Aflutter_onnx_example%2Fmain.dart/17fdb270372\",\"uri\":\"package:flutter_onnx_example/main.dart\",\"_kind\":\"kernel\"},\"tokenPos\":1494},\"function\":{\"type\":\"@Function\",\"fixedId\":true,\"id\":\"classes/4341/functions/build\",\"name\":\"build\",\"owner\":{\"type\":\"@Class\",\"fixedId\":true,\"id\":\"classes/4341\",\"name\":\"_MyAppState\",\"_vmName\":\"_MyAppState@564463603\",\"location\":{\"type\":\"SourceLocation\",\"script\":{\"type\":\"@Script\",\"fixedId\":true,\"id\":\"libraries/@564463603/scripts/package%3Aflutter_onnx_example%2Fmain.dart/17fdb270372\",\"uri\":\"package:flutter_onnx_example/main.dart\",\"_kind\":\"kernel\"},\"tokenPos\":364,\"endTokenPos\":1766},\"library\":{\"type\":\"@Library\",\"fixedId\":true,\"id\":\"libraries/@564463603\",\"name\":\"\",\"uri\":\"package:flutter_onnx_example/main.dart\"}},\"_kind\":\"RegularFunction\",\"static\":false,\"const\":false,\"implicit\":false,\"_intrinsic\":false,\"_native\":false,\"location\":{\"type\":\"SourceLocation\",\"script\":{\"type\":\"@Script\",\"fixedId\":true,\"id\":\"libraries/@564463603/scripts/package%3Aflutter_onnx_example%2Fmain.dart/17fdb270372\",\"uri\":\"package:flutter_onnx_example/main.dart\",\"_kind\":\"kernel\"},\"tokenPos\":1337,\"endTokenPos\":1764}},\"code\":{\"type\":\"@Code\",\"fixedId\":true,\"id\":\"code/a8b3c23b28-70b48040a030\",\"name\":\"[Unoptimized] _MyAppState.build\",\"_vmName\":\"[Unoptimized…

So I assume this is just the same issue with source references not being correctly resolved from file to package. App structure seems to be irrelevant (the same issues are experienced running a sample app or the example subfolder of a sample plugin).

Setting the cwd or packages options in launch.json does not help unfortunately.

It sounds like this is being worked on in the new debug adapters, so filing more for posterity than anything but if you have any immediate suggestions, I'm all ears.

flutter doctor

[✓] Flutter (Channel stable, 2.10.4, on Fedora 34 (Workstation Edition) 5.13.9-200.fc34.x86_64, locale en_SG.UTF-8)
    • Flutter version 2.10.4 at /mnt/hdd_2tb/flutter
    • Upstream repository git@github.com:flutter/flutter.git
    • Framework revision c860cba910 (5 days ago), 2022-03-25 00:23:12 -0500
    • Engine revision 57d3bac3dd
    • Dart version 2.16.2
    • DevTools version 2.9.2

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /home/hydroxide/Android/Sdk
    • Platform android-31, build-tools 31.0.0
    • Java binary at: /home/hydroxide/Downloads/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.11+0-b60-7590822)
    • All Android licenses accepted.

[✗] Chrome - develop for the web (Cannot find Chrome executable at google-chrome)
    ! Cannot find Chrome. Try setting CHROME_EXECUTABLE to a Chrome executable.

[✓] Android Studio (version 2020.3)
    • Android Studio at /usr/local/android_studio/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 11.0.10+0-b96-7249189)

[✓] Android Studio (version 2021.1)
    • Android Studio at /home/hydroxide/Downloads/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 11.0.11+0-b60-7590822)

[✓] VS Code (version 1.59.1)
    • VS Code at /usr/share/code
    • Flutter extension version 3.25.0

[✓] Connected device (1 available)
    • Android SDK built for x86 64 (mobile) • emulator-5562 • android-x64 • Android 10 (API 29) (emulator)

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 1 category.

[DanTup]

@nmfisher are you attaching or just running from VS Code? If running, then I suspect this is a different issue. For the breakpoints that don't work, do you mean that VS Code pauses without jumping to the location, or that it does not break at all?

Setting breakpoints by file:/// paths should work fine. This issue is about the VM pausing in a package:// and us not correctly mapping it back to the file so we can tell VS Code which location to jump to. When we run we know how to do this mapping, but when we attach we don't know where the .packages/package_config.json mapping file is unless you set cwd/packages (or we use the new APIs).

If you can provide detailed instructions for me to reproduce this (including the port forwarding you're setting up etc.) I can do some debugging, though if it's not attach then it's worth opening a new issue for it, as it's probably something different.

Out of curiosity - why are you using the remote Linux machine but connecting ADB back to the Windows machine? (it's always useful for me to understand more about the less common workflows so in case they're not as well supported as they could/should be!).

[nmfisher]

Thanks for the quick response @DanTup. I tried both attach and launch from VS Code, but both have the same problem - specifically, that VS Code doesn't pause/jump at all when a breakpoint is set/hit in "app" code. It does work as it should, however, when an exception is thrown, when a breakpoint is hit in Flutter framework code or external package code, or when debugger() is called.

Right now it's just so I can run the Android emulator (or connect an actual device) to my laptop while I'm out and about, while keeping the working codebase and running the actual Flutter compiler on a more powerful Linux machine. Admittedly it's a bit of an unconventional setup, but it is similar to the use case where Flutter is run via WSL and the emulator is run on the underlying Windows host (which seems to be a lot more common, judging from GitHub issues).

I'll try and put together a reproduction repository/image.

[nmfisher]

I've been tearing my hair out today trying to understand why everything worked fine in a Docker image I put together, but still not in the original Linux environment that was very similar.

That's until I realized that in my original environment, VS Code Remote SSH was actually opening the Flutter project folder at a symbolic link, not the actual filesystem location. I created a sample project on Linux to check, and it seems that indeed, breakpoints do not work if folders are opened via symbolic link.

So forget about port forwarding/Remote SSH, I'm pretty sure the underlying problem can be replicated as follows (all on Linux):

1. Run the Android emulator.
2. Run the following on the command line:

cd ~
flutter create flutter_test_project
ln -s flutter_test_project $(pwd)/flutter_test_project_link

3. Run VS Code and open ~/flutter_test_project folder
4. Set a breakpoint at _incrementCounter line 54 in main.dart, hit F5 run
5. In emulator, once the app is running, click the + floating action button, VS Code should pause/highlight on the breakpoint as expected
6. In VS Code, close the ~/flutter_test_project folder and open the ~/flutter_test_project_link folder
7. Set the same breakpoint as (4), hit F5 run
8. In the emulator, click the + button and see that VS Code does not pause on the breakpoint.

I confirm that opening the remote SSH folder at the actual filesystem location, not the symbolic link, resolves my issue and everything is working as intended.

[DanTup]

Thanks for the debugging! I can't repro on macOS - I'm unable to open a symlink folder in VS Code.. no matter if I use code linked_folder, cd linked_folder && code . or File -> Open Folder, it always opens the resolved folder (and then everything works fine).

I'll have a go with Docker and see if I can repro on Linux - in case I can't with Ubuntu, what distro are you using?

[DanTup]

Since this is different to the original issue here, let's continue this at #3896.

[DanTup]

I've confirmed this issue is resolved when using the new SDK DAPs. If you're using Flutter 3.0 or newer you can switch to these now with a flag in your VS Code settings:

"dart.previewSdkDaps": true

However, there are a few known issues when running on Web/Chrome devices with that version so I won't be starting to enable this by default until the next (non-hotfix) Flutter release that includes a few fixes for that.

I'll keep this issue open until closer to when that ships to include in release notes of a closer release.

[DanTup]

I've re-tested this on the current Flutter beta (v3.3.0-0.5.pre) with the latest Dart extension and dart.previewSdkDaps: true and confirmed it's all working as expected.

The new SDK DAPs will be gradually become default over the coming months (though you can still opt-in with that flag) when you're using a new enough SDK.

[Nikzed]

I've confirmed this issue is resolved when using the new SDK DAPs. If you're using Flutter 3.0 or newer you can switch to these now with a flag in your VS Code settings:

"dart.previewSdkDaps": true

However, there are a few known issues when running on Web/Chrome devices with that version so I won't be starting to enable this by default until the next (non-hotfix) Flutter release that includes a few fixes for that.

I'll keep this issue open until closer to when that ships to include in release notes of a closer release.

not really helping, it somehow just stopping process at start

[DanTup]

@Nikzed can you open a new issue with a detailed description of the issue you're seeing, and if possible a code sample/project that reproduces it? Thanks!