Invalid argument(s): Uri org-dartlang-sdk:///lib/_internal/js_dev_runtime/private/ddc_runtime/rtti.dart must have scheme 'file:'. #43589
Comments
|
I wanted to add the label |
mit-mit
added
area-web
|
@jakemac53 Do you think this is a build_web_compilers issue? |
|
This error essentially means I believe that it tried and failed to read the file When the multi-root file system fails to find a file, I believe it then tries to delegate the read to the standard file system, which then throws this error because it doesn't support that scheme. |
|
@alextekartik I wasn't able to reproduce this issue locally. I have Dart SDK 2.10.0-110.5.beta and I checked out your repo https://github.com/tekartik/browser_utils.dart at master. Have you reproduced this on your local machine or only on travis? |
|
@nshahan It seems to happen only on travis which indeed is a pain. I think it comes from this project (https://github.com/tekartik/js_utils.dart/tree/master/js_utils) which also fails with the same error: https://travis-ci.org/github/tekartik/js_utils.dart/jobs/731662766 It worked on 2.10.0-110.3.beta and fails consistently on 2.10.0-110.5.beta without change. If I get time I will try to remove code from it (it is a small js interop project) to get a minimum reproducible scenario if that could be helpfull |
Thanks! Ideally a minimal repro that displays the issue locally would be the best. |
|
Ok the smallest I came too was the creation of an anonymous JS object such as this one: @JS()
@anonymous
class WithIntValue {
external int get value;
external set value(int value);
external factory WithIntValue({int value});
}Just adding: var withIntValue = WithIntValue();in a unit test make the test (well...the compilation) fails on travis with the same reported error. I remember having a similar issue once on my linux box but I cannot reproduce it... Minimum repro travis job: https://travis-ci.org/github/tekartikdev/js_utils.dart/builds/731779145 In the mean time my workaround is to not call |
… dart 2.10.0-110-5 beta issue: dart-lang/sdk#43589
|
@jakemac53 Is there anything you see in the travis logs from above that stands out as being different than what you would get locally? |
|
I don't see anything obvious, no :(. I also tried to locally repro using exactly that version of the sdk that travis used and couldn't repro it with that either. |
|
Progress update: @jakemac53 and I were investigating and were able to reproduce it locally but only very rarely. This suggests there is a timing issue that is triggered more consistently when running on travis. When it did actually fail we were able to determine that the cause of the crash is the contents of the source maps. It appears that a file from the SDK is included in the sources for the module being compiled. See: We have ideas to work around the issue and avoid crashing but would like to find the root cause. It is unexpected that the sources from the SDK should be included here and suggests that for some reason the file from the SDK is being compiled within a module unnecessarily. |
|
Progress update: We have identified the reason this is hard to reproduce. The ddc worker that compiles the SDK module must also compile the module with the repro in it. Travis jobs run with fewer workers so it is more likely to happen than on a local build. You can reproduce locally by setting an environment variable before running the build I have a potential fix in progress. The issue is caused by a cache of templates used to create JS code that can contain sourcemap information. If they have that information they should not be cached. |
|
@nshahan Thanks for the progress. I'm definitely getting this issue from time to time on my linux box. I'll be happy to help you in testing your solution. Good luck! |
|
It looks like you guys have this figured already, but in case another example of the issue is helpful, here's a case where I saw it in Travis on the |
|
@greglittlefield-wf Thanks for another example. Funny timing, I just sent a fix out for review. We are discussing the right way to distribute it still. Although the bug exists in the Dart SDK, as a temporary work around you can avoid triggering it by using a version of |
JS templates should always use their own source information. DDC was incorrectly caching and reusing templates with the same source information in various parts of the program. This lead to incorrect source maps and in some cases compiler crashes when the source map in a user application pointed to source location in the SDK. Change-Id: I11607e6f02b894ead1d350e9b3071173ba36a048 Fixes: #43589 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/166122 Reviewed-by: Mark Zhou <markzipan@google.com> Reviewed-by: Sigmund Cherem <sigmund@google.com> Commit-Queue: Nicholas Shahan <nshahan@google.com>
I have a github project that started failing on the beta branch since Dart SDK version: 2.10.0-110.5.beta
https://travis-ci.org/github/tekartik/browser_utils.dart/jobs/730257382
The command:
The error:
It worked fine on 2.10.0-110.3.beta: https://travis-ci.org/github/tekartik/browser_utils.dart/jobs/728330156
It also works fine on the stable branch.
It fails consistently which is why I reported it.
The text was updated successfully, but these errors were encountered: