Repository navigation
Support passing arbitrary DartVM flags to Flutter #32176
Description
Feature request: add a dart_tools command line argument to support passing safe DartVM flags for debug and profile builds only.
Proposed name: --dart-flags
This is a development time only feature similar in intent to the --js-flags feature provided by Chrome. For example, in Chrome you can write
chrome.exe --js-flags="--trace-opt --trace-deopt --trace-bailout"
to launch chrome with custom JavaScript VM flags.
There is already a dart-flags flag in the flutter engine but it is not exposed by flutter_tools so it is impossible to run an app with the flag on without either editing the engine or editing the code for each of the platforms an app supports (e.g. IOS, Android, etc).
https://github.com/flutter/engine/blob/1c9457cedc51eb2f109a4a30da57b2daae0c1fd3/shell/common/switches.cc#L265
Before exposing --dart-flags further we should make this code not execute at all in release mode to avoid future bugs. A couple lines bellow in this file there is code to ignore some of the functionality outside of release mode.
A curated set of VM flags are exposed through flutter_tools but the list is incomplete and flags have to be added in a large # of places so it is impractical to add flags just for one off experiments such as changing the stack trace depth used for the sampling cpu profiler.
Example showing how many locations must be modified to flow through the VM flag start-paused:
https://github.com/flutter/engine/search?q=start-paused&unscoped_q=start-paused
https://github.com/flutter/flutter/search?q=start-paused&unscoped_q=start-paused
https://github.com/flutter/flutter/search?q=start-paused&unscoped_q=startPaused
It would be a good idea to provide a warning on app startup if custom Dart-VM flags are passed in to ensure this is used for one-off experiments rather than for typical user work flows. This is similar to how chrome will warn you if you are running with with non-standard flags.
Considerations:
We should ensure the flags are only passed in in debug and profile builds and never release builds. This is best done by ignoring the command line arguments completely in release builds. It would also be safest if the flags cannot be set by arguments to an android intents and similar even in a debug build so there are not any surprises on when the flags are set.
One option for added safety is to have a curated list of Dart VM flags in the DartVM adding a Dart_SetSafeVMFlags method similar to the existing Dart_SetVMFlags. This would further ensure users do not turn on VM flags that are not recommended for users outside the VM team.
Activity
bkonyi commentedon May 17, 2019
@a-siva, @rmacnak-google can you think of any reason why we wouldn't want to have a separate
Dart_SetSafeVMFlagsAPI? It would save a lot of hassle to have this to allow for a--dart-flagsoption in flutter_tools instead of plumbing each valid flag through individually.rmacnak-google commentedon May 17, 2019
The VM has no notion of a safe flag. This is extra policy added by Flutter, so Flutter is responsible for deciding what flags they allow and the associated plumbing.
jacob314 commentedon May 17, 2019
I'm happy to help triage which flags are safe and which aren't. The goal is to keep the notion of safe flags in the VM instead of in Flutter for better robustness. I would want someone on the VM team to be able to tell that a flag is being treated as safe without having to look at the flutter code. That way if a change is made to the VM that makes a certain flag unsafe, the VM authoer is aware it is treated as safe.
rmacnak-google commentedon May 17, 2019
Again, the VM does not warrant any flags as safe.
bkonyi commentedon May 17, 2019
I think I'll have to side with Ryan on this one, but there's nothing stopping us from adding a
--dart-flagsoption to flutter_tools and doing the check for "safe" flags there or in the engine. This sort of check probably shouldn't be living in the VM since it is a choice made by Flutter to restrict which flags can be used in the first place.jacob314 commentedon May 17, 2019
I'd like to clarify what I mean by safe. Safe does not mean safe in the sense of avoiding having the VM crash. Safe just means that the VM does not do something like expose a websocket without any security checks. Perhaps there is a better name to clarify the intent.
a-siva commentedon May 17, 2019
I agree that it makes sense to have the flutter layer control the flags passed to the VM.
jacob314 commentedon May 17, 2019
Ok. We can add a whitelist of safe flags to the flutter_engine instead. That seems a bit less robust than specifying the safe flags in the VM as we will miss new safe flags that are added but it should work reasonably and avoid us accidentally allowing new unsafe flags.
Allow for whitelisted flags to be passed to the Dart VM
Allow for whitelisted flags to be passed to the Dart VM (#9148)
Allow for whitelisted flags to be passed to the Dart VM (flutter-team…
github-actions commentedon Aug 29, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.