The dart run argument parser was incorrectly parsing any argument following an
option that the VM treats as having a default (e.g., --observe and
--enable-vm-service), resulting in a "File not found ''" error and the
VM failing to start the user program. The following invocations would
fail due to 'foo.dart' being treated as the value for the option to the
left:
- dart run --observe foo.dart
- dart run --enable-vm-service foo.dart
This change strips these two options from the arguments sent to dartdev
as both are handled directly in the VM and are only included in the dart
run argument parser for the help message.
Fixes https://github.com/dart-lang/sdk/issues/55185
TEST=regression test added to run_test.dart.
Fixed: 55185
Change-Id: I1c89fec3ee46296ee4ebb847eb47a7845dfdb399
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357360
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Android is based on Linux, so most of the files were identical
sans some subtle discrepancies caused by drift over time.
This discrepancies were making code base harder to maintain and in fact
were hiding bugs. For example, on Android eventhandler's implementation
of timers which relied on passing timeout to `epoll_wait` contained
a bug which was not present on Linux which used `timerfd` instead.
TEST=ci and manual testing of Flutter app on Android device
Fixes https://github.com/dart-lang/sdk/issues/54868
Cq-Include-Trybots: luci.dart.try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-android-product-arm-try,vm-ffi-android-product-arm64c-try,vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64c-try
Bug: b/311165013
Change-Id: Ia166f69c14177ec34160805a0983eafee8ea65f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350923
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This CL makes `FfiNative`s use `DynamicLibrary.process()` lookup if
resolving with the resolver set by `Dart_SetFfiNativeResolver` fails.
Also moves the implementation over from ffi.cc to
ffi_dynamic_library.cc so the implementation can be shared with
`DynamicLibrary.process()`.
Moves the implementation behind non-simulator and non-precompiler.
However, the implementation is tested in vm/cc tests which are in
precompiler mode. So enables the implementation if TESTED is defined.
This CL massages the build files so that TESTED is properly
defined when compiling the runtime for the vm/cc tests, and links
the ole32 symbols on windows for vm/cc tests.
(And some unrelated small cleanup changes here and there.)
TEST=tests/ffi/native_assets/process_test.dart
Change-Id: I25395d381db1d9b4b7a5759171a798a1140a6140
Cq-Include-Trybots: luci.dart.try:vm-kernel-win-debug-x64c-try,vm-kernel-win-debug-x64-try,vm-kernel-nnbd-win-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,dart-sdk-win-try,vm-kernel-win-release-x64-try,vm-kernel-win-release-ia32-try,vm-kernel-precomp-win-product-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264982
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This adds [sendMessage] and [receiveMessage] methods to [RawSocket] class. They are only supported on Linux at the moment as they require connection opened as unix domain socket connection.
This introduces [SocketControlMessage] class that represents a message sent via socket and also introduces [ResourceHandle] class that wraps [RandomAccessFile], [Socket]/[RawSocket]/[RawDatagramSocket], [Stdin]/[Stdout] for
marshalling/unmarshalling purposes.
Underlying OS implementation supports various kinds of control messages that can be passed via sockets, this CL only adds support for sending/receiving opened file description handles.
When receiving a message recipient can attempt to extract handles out of it via [tryExtractHandles]. It returns [null] if message has no handles to extract.
This is continuation of the work started on https://dart-review.googlesource.com/c/sdk/+/205067.
Bug: https://github.com/dart-lang/sdk/issues/46328
TEST=unix_socket_test
Change-Id: Ic9125b51dc80b677452e454366bae4118c298081
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212036
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
The 'File' object created in the async file open method is leaked
if the operation is not completed when the isolate shuts down
with an unhandled exception.
This change adds a finalizable state for the 'File' object so that
the message deletion that happens when ports are closed could run
the callback to clean up the 'File' object.
TEST=new tests added
Change-Id: I64c18a7905261b0fc7bf9f220086791478232d0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211340
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This reverts commit b67f45f955.
Reason for revert: This seems to cause a crash on ARMv7 aot compiled code.
Original change's description:
> [VM/Runtime] Fix 'File' object leak in async file open operation
>
> The 'File' object created in the async file open method is leaked
> if the operation is not completed when the isolate shuts down
> with an unhandled exception.
> This change adds a finalizable state for the 'File' object so that
> the message deletion that happens when ports are closed could run
> the callback to clean up the 'File' object.
>
> TEST=new tests added
>
> Change-Id: I4a3cb28370d27306c795c1914aeb5c18a1d85e2b
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210761
> Reviewed-by: Alexander Aprelev <aam@google.com>
> Commit-Queue: Siva Annamalai <asiva@google.com>
TBR=aam@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Ie91aadd318ef19a0bb4d7f769c9e876e76d719d8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211021
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: William Hesse <whesse@google.com>
The 'File' object created in the async file open method is leaked
if the operation is not completed when the isolate shuts down
with an unhandled exception.
This change adds a finalizable state for the 'File' object so that
the message deletion that happens when ports are closed could run
the callback to clean up the 'File' object.
TEST=new tests added
Change-Id: I4a3cb28370d27306c795c1914aeb5c18a1d85e2b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/210761
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Instead of just giving up try to give as much information as possible
including error code, error returned by Dart_StringFromUtf8 and
ascii portion of the OS error message.
We are making this change because we are getting reports of
ProcessException being thrown with "OS error message was a
not a utf8 string." message. There is no way to reproduce
these situations so instead we are going to add additional
information into the fallback message to aid the investigation.
TEST=tested manually by simulating fallback to the newly added code
Bug: b/178383611
Change-Id: Idf528dc762723694145a15aa07320220e8af9bfc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/181200
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Changes Dart_NewWeakPersistentHandle to no longer auto delete the
weak persistent handle.
Changes the signatures of WeakPersistentHandleFinalizers to no longer
have access to the handle.
Flutter PR: https://github.com/flutter/engine/pull/19843
g3 presubmit: cl/318028238
Issue: https://github.com/dart-lang/sdk/issues/42312
TEST=runtime/vm/dart_api_impl_test.cc
Change-Id: I3f77db9954d9486759f903b78c03a494f73c68ba
Cq-Include-Trybots:dart/try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,app-kernel-linux-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-android-release-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-precomp-msan-linux-release-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,dart-sdk-linux-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,front-end-linux-release-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-mac-debug-x64-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-nnbd-linux-debug-x64-try,analyzer-nnbd-linux-release-try,front-end-nnbd-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151525
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit bc4cb123a8.
Reason for revert: breaks crossword simarm tests https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-precomp-linux-debug-simarm_x64/2619
Original change's description:
> Reland "[ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process"
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
>
> This reverts commit 3849b5061c.
>
> Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I649d94c668417f2edbfd7039fa5c876e10dc32fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154800
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
This reverts commit 3849b5061c.
Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit ffe258d2d4.
Reason for revert: Failures on bots
Original change's description:
> [ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
>
> Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Idb1d24a4524bdc3ccfb199a82710f3c0d9db539a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154702
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This reverts commit 29e93bcdbd.
Reason for revert: Windows bots are failing with package resolution
errors. Looks like we are missing a windows path sanitization step.
Change-Id: Ib56f7e926b4f385fa3fde74c9c71947f64b8be1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/151469
Reviewed-by: Siva Annamalai <asiva@google.com>
In order to reduce confusion, if a VM instance detects that it will be
running a dartdev snapshot it will ignore all VM flags and print a
warning message to stderr informing users that the flags are being
ignored and that they should be passed immediately after the 'dart run'
command. This will prevent the dartdev snapshot from being run with
incompatible flags in addition to preventing users from accidentally
setting flags for the dartdev VM when they meant to set those flags for
the target process.
As usual, passing --disable-dart-dev will allow for the user to bypass
this behavior and run their dart program directly.
Fixes https://github.com/dart-lang/sdk/issues/41590
Change-Id: I7d5dc3d4ddae8be99994620b5b2c2e4cc492ae5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/146984
Reviewed-by: Siva Annamalai <asiva@google.com>
- Removes the load port functionality from the service isolate, this was
used to load sources in Dart 1 and is pretty much dead code in Dart 2
- Moves resolution of URIs and Package URI (based on package map) to the
individual isolates instead of sending a request to the service isolate
- Setups the package map lazily as it is needed only if resolveURI is
called in Dart code, it is not needed for loading/compiling sources
(this is now done in the front end).
- Removed Dart_ServiceWaitForLoadPort() methods from the Dart C API as
it is not used anywhere.
Change-Id: I6c3704bc431bdcd49bf074eb58bee1ed492ccccb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/129742
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Given a source file that starts with '#@dill' on a new line, then if the rest of the lines are full paths to the kernel dill files, all kernel dill files will be loaded and executed as single program.
So, for example, given `mytest.dillref` with following content:
```
/projects/mytest/build/bin/main.vm.dill
/projects/mytest/build/packages/mytest/lib.vm.dill
```
invocation of `dart mytest.dillref` will result in loading two dill files and starting combined app.
Bug: dartbug.com/33952
Change-Id: I22a99ec9a018da1bc984bc0d716af94bc10e20d6
Add few tests
Change-Id: I22a99ec9a018da1bc984bc0d716af94bc10e20d6
Reviewed-on: https://dart-review.googlesource.com/67460
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This enables other emdedders to reuse parts of the standalone embedder
implementation without depending too much on the implementations details.
As part of the change we also remove a dependency from DartUtils on
IsolateData - by removing dart:_builtin library caching. Lookup
of this library does not seem to be on hot path anymore in Kernel world.
Change-Id: Ia35b28886121828fad7a96f00bcbceff75e00ae8
Reviewed-on: https://dart-review.googlesource.com/64848
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reason for revert: Breaking API change blocks Flutter rolls. Reverting
to reconsider, work around, etc..
Revert "[ VM ] Fixed issue where backing array was deleted from an ExternalTypedData before the ExternalTypedData was used."
This reverts commit 916b9da48d.
Revert "[ VM ] Fixed tests for non-UTF8 paths on Windows / Macos."
This reverts commit 6327fe91c2.
Revert "[ VM ] Fix failing tests on Windows bots after non-UTF-8 paths change."
This reverts commit b51f4b7956.
Revert "[ VM ] Updated non-UTF-8 tests to expect exceptions on OSX/iOS."
This reverts commit bcb36247d2.
Revert "Revert "[ VM ] Updated non-UTF-8 tests to expect exceptions on OSX/iOS.""
This reverts commit 24450c79a5.
Change-Id: I756f74f4acdde168d0984fe130f05f9252366334
Reviewed-on: https://dart-review.googlesource.com/55441
Reviewed-by: Todd Volkert <tvolkert@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
Reland "Fix issues with FileSystemEntities which have non-UTF8 paths causing exceptions to be thrown when converting to/from a Dart VM String."
This reverts commit 4f549e2900.
Change-Id: Ia27c8c300beb178fa7b08ffe0bfcb2d61f65bbb5
Reviewed-on: https://dart-review.googlesource.com/55271
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Update status for simulators, which the test harness invokes with DIL files instead of source files.
Change-Id: I8444ad7e17a0a71a1ce3c0021487397baa1c3e65
Reviewed-on: https://dart-review.googlesource.com/54622
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Derek Xu