You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Attaching to running flutter process doesn't highlight source paused on #3808
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:
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 .)
Start the flutter app using the CLI on a connected (android) device (flutter run)
Attach to the running flutter app on the connected device
Set a breakpoint, ensure the corresponding code is executed
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
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.
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.
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
},
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.
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:
However, I can also see that the scriptUri reference uses file:/// references, whereas the (correctly functioning) Exceptions are referenced using package:... notation:
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 [email protected]: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.
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.
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.
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
@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!
Activity
DanTup commentedon Feb 1, 2022
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 thecwdto the folder that contains the app (and then useF5/Run -> Start Debuggingto start the attach process) then we'll use that to find the packages file ourselves that lets us perform the mapping:.vscode/launch.json
I'll keep this issue open to ensure this is not required when we switch to the new DAPs.
t-animal commentedon Feb 1, 2022
Unfortunately the suggested workaround doesn't work in my case. It prints the following on its debug console:
The configuration works if I leave out "cwd", but however I specify the cwd (relative, absolute...) it prints the above.
DanTup commentedon Feb 1, 2022
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:
although I suspect it may do the same thing.
DanTup commentedon Feb 1, 2022
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 commentedon Feb 2, 2022
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:
DanTup commentedon Feb 2, 2022
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 commentedon Mar 30, 2022
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.
(it may be relevant that the Dart extension is installed both locally and remotely).
What works:
debugger()fromdart:developeris invoked (though the line number in the source file might be slightly off).What doesn't work:
Note that the breakpoints are definitely successfully set:
However, I can also see that the scriptUri reference uses
file:///references, whereas the (correctly functioning) Exceptions are referenced usingpackage:...notation: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
cwdorpackagesoptions inlaunch.jsondoes 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
5 remaining items
DanTup commentedon Jun 21, 2022
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:
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 commentedon Aug 25, 2022
I've re-tested this on the current Flutter beta (v3.3.0-0.5.pre) with the latest Dart extension and
dart.previewSdkDaps: trueand 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 commentedon Jul 7, 2023
not really helping, it somehow just stopping process at start
DanTup commentedon Jul 7, 2023
@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!