Debugging crashes in one (and only one) VSCode flutter project

[MrLarryQ]

My PC restarted itself yesterday and VSCode restarted with it.  I was working with this repository on state management and now whenever I try to debug it in VSCode I get the following:

The built-in library 'dart:ui' is not available on the stand-alone VM.

'package:reactive_exploration/common/models/catalog.dart': error: line 4 pos 1: library handler failed

import 'dart:ui' show Color;

I deleted the repo on my local box, re-cloned the repository and still have that trouble.  I had no trouble debugging this project before the PC restarted, and I have no trouble debugging any of my other flutter projects in VSCode. 

I can run this project using flutter run without issue, it's debugging that gives me the error above.  I've looked all over and can't figure out what to try next?  

[Greg Spencer]

I wonder if there's something broken in your pub cache?  Try renaming your ~/.pub-cache directory (%APPDATA%\Pub\Cache on Windows) to something else, and see if that fixes it. (If it does, then you can just delete the old pub cache).

-Greg.

--
You received this message because you are subscribed to the Google Groups "Flutter Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flutter-dev...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kris Giesing]

There's a setting in the Dart Configuration area that talks about the location of the "Flutter Sdk Path". I wonder if this setting is somehow set for that specific project and not others?  The wording of the setting also suggests there may be logic that depends on the folder location (emphasis mine): "The location of the Flutter SDK to use. If blank, Dart Code will attempt to find it from the project folder, FLUTTER_ROOT environment variable and the PATH environment variable."

It would be worth checking that setting to see if anything looks different between the projects that work and those that don't.

Hope this helps,

- Kris

[MrLarryQ]

Hmm, I can't seem to find a \pub\cache directory on my box.  I've looked in c:\users\myname\appdata, and all I have are 'Local', 'LocalRaw' and 'Roaming' folders.  None of them has a Pub folder beneath them, either.  Is there a file(s) I can search for under the APPDATA folder, to try and spot where the cache is?  

Is there a command in Dart or Flutter I can use to find where the cache is?

[Greg Spencer]

Well, there's not a command to just print your pub cache directory (we should probably consider adding one), but if you go to the "examples/flutter_gallery" directory in the flutter root and run "flutter -v packages get", some of the output (the lines that begin with "Found plugin") will show where the pub cache is.

The other place it can be is in your flutter directory, called .pub-cache, but probably only if you originally downloaded flutter as a package and didn't clone it from git.

-Greg.

[MrLarryQ]

Thanks.  I've looked in the VSCode File--->Preferences---->Settings  section of both this and another (debuggable) flutter project, and they each have identical dart.flutterSdkPath settings.  Not sure if that's the setting you had in mind or that I should look elsewhere?  

[MrLarryQ]

Thanks.  I ran the command you suggested and found the SDK path that way, and renamed .pub-cache.  

I had to run flutter packages get to re-build my projects, so that must have been the right location for the cache, but the same problem is happening-- I can debug two other flutter projects, and can run this troublesome one, but can't run the debugger on it.  I still get the same error message as before.  Talk about bizarre!

[Greg Spencer]

Well, I think that just means that it didn't have to do with the pub-cache, unfortunately.

Hmm. Yeah, that's pretty bizarre. I'm kind of stumped.

Have you removed any build/ directories with "flutter clean"? (this should have happened when you deleted your repo and re-cloned it, but maybe they're accidentally checked in?)

Are you using/building your own Flutter engine, or supplying flags on the command line to override the engine location? (yeah, really esoteric, and probably not it, but hey).

The dart:ui package comes from the engine in the $FLUTTER_ROOT/bin/cache directory, so maybe something is odd with that, but if that were the case I don't understand why any projects would build.

Just for grins, you could try nuking the bin/cache directory in your flutter root, and then running flutter again and let it download all the components. To be honest, I don't think that will work, but I'm out of other ideas.

-Greg.

[Kris Giesing]

Is there anything special about the path to the failing project, like containing spaces, or Unicode characters? (I'm kind of stumped as well.)

[MrLarryQ]

The path to the project is "F:\temp\state_experiments2", so no weird characters in there, nor in any subdirectories, no spaces in the paths either.  

It's called 'state_experiments2' because it was initially 'state_experiments' before I blew away the folder and re-cloned.  I changed the path name just for completeness' sake.

I'll keep poking at this and if I find something that works will be sure to post it here.  I appreciate the help from you guys, thanks for taking a few swings at this with me.

[Danny Tuppeny]

On Thursday, 11 October 2018 21:42:54 UTC+1, MrLarryQ wrote:

My PC restarted itself yesterday and VSCode restarted with it.  I was working with this repository on state management and now whenever I try to debug it in VSCode I get the following:

The built-in library 'dart:ui' is not available on the stand-alone VM.

'package:reactive_exploration/common/models/catalog.dart': error: line 4 pos 1: library handler failed

import 'dart:ui' show Color;

Usually this message means we're trying to run your project with Dart instead of Flutter. When you open the project, if we detect it as Flutter you should see the Flutter version (and currently selected device) in the bottom right of the status far - if you're not seeing them, it means we think it's just a Dart project (and will therefore run as Dart). Even if we do detect it as Flutter, there are few reasons we might still choose to launch with Dart - for example if you're trying to run a script from the bin/ or tool/ folder (since Flutter entry points are in lib).

The most common cause of this kind of issue is opening an ancestor folder of your Flutter project (we only look in the pubspecs of root workspace folders) but it's hard to say without more info. If you enable the extension log and reproduce the issue, then check the log, it should write information about how it detected the project type and how it selected which debugger to run. If it's still not clear, email the log to me or open an issue in the Dart-Code repo and I'll take a look.

Thanks!

[MrLarryQ]

That fixed it.  What I had downloaded from the github repo were in fact three flutter projects under a root folder:

hello_world

hello_world_start

shared

I opened the root folder in VSCode (which doesn't have a pubspec file) and saw all three of those subfolders.  I then navigated to the 'shared' folder (where the good stuff is and where the pubspec file lives for that project) and could run the project with flutter run, but not debug it.  

Now, if I open the 'shared' folder directly in VSCode instead of the root folder, I can debug the project as well as run it.  Works great.

 I must have done the same the first time through, before my PC restarted, but I don't remember it.  So my eternal gratitude to you for figuring this out.  If I could ask just one more debugging question in VSCode before moving on, how does the debugger know which file to use as its entry point when you start debugging?  Does it look for, say, main.dart in the lib folder as a default?

-Larry

[Danny Tuppeny]

On Sun, Oct 14, 2018 at 7:03 AM MrLarryQ <lqu...@gmail.com> wrote:

That fixed it.  What I had downloaded from the github repo were in fact three flutter projects under a root folder:

Glad you got it sorted! I'm not entirely happy with how this works in VS Code right now, but haven't come up with a good solution. If you do File -> Open and then use <Shift> to select all three of those folders in the Open dialog, it'll mark each one as a root. It'll look mostly the same, but it won't have this issue, since VS Code will allow debug config for each folder that you can switch between on the Debug Sidebar.

For a while, there was a prompt that would offer to automatically switch your open folder to this mode, but it wasn't entirely obvious what it meant so it just felt like an annoyance and I removed it. I think there's still room for improvement here though, so I'll make a note to think about this again. Something that would help in this area is this VS Code feature so please a 👍 on that issue would be appreciated :-)

I must have done the same the first time through, before my PC restarted, but I don't remember it.  So my eternal gratitude to you for figuring this out.

Thanks, though I can't really take credit, it's my fault it's not as clear as it could be ;-)

 

If I could ask just one more debugging question in VSCode before moving on, how does the debugger know which file to use as its entry point when you start debugging?  Does it look for, say, main.dart in the lib folder as a default?

Pretty much! Check the guessBestEntryPoint function here:

https://github.com/Dart-Code/Dart-Code/blob/dcb1638292f8d2188ad83b7e69a1673d9afcde66/src/providers/debug_config_provider.ts#L212-L234

If the current open file looks like a test file, or is inside the bin or tool folder, we'll use that. Otherwise we'll try and find a project root from the open file (falling back to the open folder) and then look for some common files (bin/main.dart and lib/main.dart). I don't know if the logic is perfect, but it seems to work well. I really want in most cases for people to just press F5 and it'll just do the thing they expect. If the logic fails, you can specifically set the entry point with a launch.json file (setting the `program` field), though hopefully if anyone finds it picking the wrong file, they'll open issues and we can try and improve the guesswork.

[MrLarryQ]

Thanks for the debugging explanations Danny, and I've 'thumbed up' your suggestion on github.