Unable to add breakpoints in "part" files ("Unknown library" errors), "Aww, snap!" in Chrome if changed to imports #1271
Comments
|
@sigmundch this vaguely reminds me of an issue you resolved a few months ago. Do you remember the details? |
|
I'll take a look at this |
|
Sorry for the slow reply on my end - I honestly can't remember. It have this vague recollection that we used to include the library URIs without the part URIs before we had metadata files. However, if I recall correctly, @annagrin's metadata tracked part URIs pretty early on. |
|
The issue I was referring to was b/171406503. The root cause was this issue. It may not be related since the problem was caused by custom formatters but it's the only other issue I've seen where the Chrome DevTools would fully display an "Aw Snap" error. |
|
I found the issue - we are not registering module names for part uris, so looking up locations fails. Will fix and add tests. |
- Record library part paths in debugger tables properly. Make sure that we have module and library recorded for part scripts, in `MetadataProvider` and `Modules`, - Calculate locations for module atomically in `Locations`. This fixes intermittent 'Oh, snap!' in chrome due to a data race in location computation if several breakpoints are set in the same dart library. - Update test fixtures to include part files. - Add tests for frontend server and build runner scenarios. Closes: dart-lang#1271
- Record library part paths in debugger tables properly. Make sure that we have module and library recorded for part scripts, in `MetadataProvider` and `Modules`, - Calculate locations for module atomically in `Locations`. This fixes intermittent 'Oh, snap!' in chrome due to a data race in location computation if several breakpoints are set in the same dart library. - Update test fixtures to include part files. - Add tests for frontend server and build runner scenarios. Closes: dart-lang#1271
…ating locations (#1296) * Fix failing breakpoints in library part files and data race - Record library part paths in debugger tables properly. Make sure that we have module and library recorded for part scripts, in `MetadataProvider` and `Modules`, - Calculate locations for module atomically in `Locations`. This fixes intermittent 'Oh, snap!' in chrome due to a data race in location computation if several breakpoints are set in the same dart library. - Update test fixtures to include part files. - Add tests for frontend server and build runner scenarios. Closes: #1271 * Addressed CR comments * Format and build after rebase
|
Hi, I am experiencing this problem now for the first time. It's very odd, as earlier today, breakpoints were working, and now they all become unverified as soon as I start the debugger. I'm using VS Code, Dart Extension v3.74.0, Flutter Extension v3.74.0. I have Android Studio Giraffe 2022.3.1 Patch 2 installed. I typically use a Pixel 2 API 30 for my emulated phone. I have tried rebooting, doing a flutter clean, flutter pub get. I tried a new emulator, Pixel 7 Pro API 34. I checked for updates for Android Studio. I tried other Flutter projects. All Flutter projects exhibit the same behavior. I am starting using the debugger, not run without debugging. Any assistance with this would be greatly appreciated! |
Raised by @skateboarder with a repro at Dart-Code/Dart-Code#3194 (comment).
Everything works fine for non-web, but with web if the project uses
partthe breakpoints are not set (error below), and if I change frompartto imports, then I get an "Awww, snap!" page in Chrome when starting the app.The app is being run with
--no-sound-null-safety, but since it works fine on iOS I don't think that's related.I reproduced on current Flutter master.
The text was updated successfully, but these errors were encountered: