VMScript URI does not uniquely identify a script #437
Assignees
Labels
Comments
cbracken
added
the
type-bug
whesse
referenced
this issue
in dart-lang/sdk
Oct 5, 2017
After https://dart-review.googlesource.com/c/sdk/+/7588 we ended up with two crypto.dart files in the core prebuilt libraries(io and _http), which caused problem with coverage tool that relied on the fact that script uris can uniquely identify files. https://github.com/dart-lang/coverage/issues/194 was filed to handle non-unique uris. This CL ensures that core builtin libraries URIs stays unique by prefixing them with 'dart:' library prefix. This makes core builtin libraries scripts have names similarly structured to script names for other core libraries. Bug: Change-Id: I79960f4f24e6e958836df866365355584c28df27 Reviewed-on: https://dart-review.googlesource.com/11140 Commit-Queue: Alexander Aprelev <[email protected]> Reviewed-by: Ryan Macnak <[email protected]>
amirh
referenced
this issue
in flutter/flutter
Jan 5, 2018
This broke the coverage tool, as material/animated_icons/animated_icons.dart was loaded twice as a part, once directly animated_icons_private_test, and one through animated_icons_private_test->flutter_tester->...->material The coverage package assumes a 1:1 mapping between VM scripts and URIs due to a limitation in the underlying vm_service_client package, which currently doesn't provide a unique identifier for VM scripts. The underlying issue is tracked by dart-lang/coverage#194.
|
This was failing the coverage tool when running on animated_icons_private_test, stack trace was: |
cbracken
referenced
this issue
in cbracken/coverage
Jan 5, 2018
Previously, coverage collection assumed that a script could be uniquely identified by URI, which is not a valid assumption. For example, when a part is loaded via two libraries, both of which are loaded by an isolate, the VM will track these are two scripts that map to the same URI. During collection, we now track each script by its (unique) VMScriptRef. This ensures we lookup the correct script when computing the affected line for each hit token. The hitmap remains URI based, since in the end, we want a single, unified set of line->hitCount mappings per script. Fixes dart-lang/coverage#194
DaveShuckerow
referenced
this issue
in DaveShuckerow/flutter
May 14, 2018
This broke the coverage tool, as material/animated_icons/animated_icons.dart was loaded twice as a part, once directly animated_icons_private_test, and one through animated_icons_private_test->flutter_tester->...->material The coverage package assumes a 1:1 mapping between VM scripts and URIs due to a limitation in the underlying vm_service_client package, which currently doesn't provide a unique identifier for VM scripts. The underlying issue is tracked by dart-lang/coverage#194.
cbracken
referenced
this issue
in cbracken/coverage
Oct 19, 2018
Previously, coverage collection assumed that a script could be uniquely identified by URI, which is not a valid assumption. For example, when a part is loaded via two libraries, both of which are loaded by an isolate, the VM will track these are two scripts that map to the same URI. During collection, we now track each script by its (unique) VMScriptRef. This ensures we lookup the correct script when computing the affected line for each hit token. The hitmap remains URI based, since in the end, we want a single, unified set of line->hitCount mappings per script. Fixes dart-lang/coverage#194
cbracken
referenced
this issue
in dart-archive/coverage
Oct 19, 2018
Previously, coverage collection assumed that a script could be uniquely identified by URI, which is not a valid assumption. For example, when a part is loaded via two libraries, both of which are loaded by an isolate, the VM will track these are two scripts that map to the same URI. During collection, we now track each script by its (unique) VMScriptRef. This ensures we lookup the correct script when computing the affected line for each hit token. The hitmap remains URI based, since in the end, we want a single, unified set of line->hitCount mappings per script. Fixes dart-lang/coverage#194
cbracken
referenced
this issue
in flutter/flutter
Oct 19, 2018
Coverage 0.12.3 includes a fix for dart-lang/coverage#194, which was causing errors on the flutter build bots. Linter was updated automatically as a side effect of running `flutter update-packages --force-upgrade`.
mosuem
referenced
this issue
in mosuem/tools_fork
Aug 9, 2024
Previously, coverage collection assumed that a script could be uniquely identified by URI, which is not a valid assumption. For example, when a part is loaded via two libraries, both of which are loaded by an isolate, the VM will track these are two scripts that map to the same URI. During collection, we now track each script by its (unique) VMScriptRef. This ensures we lookup the correct script when computing the affected line for each hit token. The hitmap remains URI based, since in the end, we want a single, unified set of line->hitCount mappings per script. Fixes dart-lang/coverage#194
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In at least one place in the code, we use
VMScript.urias a proxy for the ID under the assumption that they map 1:1.This is not a safe assumption.
The text was updated successfully, but these errors were encountered: