You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
control-C does not exit app on iOS device from flutter run #4875
Application running.
Type "h" or F1 for help and "q", F10, or ctrl-c to quit.
Type "w" to print the widget hierarchy of the app, and "t" for the render tree.
^CApplication finished.
Seems we should either fix the instructions or fix the behavior. I don't really care which. :)
changed the title [-]control-C does not exist app on iOS device from `flutter run`[/-][+]control-C does not exit app on iOS device from `flutter run`[/+]on Jul 18, 2016
Just tested on Android and as you note, even though we don't make the promise anymore, there's a definite difference in behaviour. Re-opening.
Here's what appears to be going on. When the terminal receives ctrl-c, it sends SIGINT to the processgroup. On iOS, one of the child processes of flutter tool is iproxy, which manages all the port forwarding we do -- in this case, that includes the observatory port forwarding. iproxy gets SIGINT and dies, which kills our observatory connection.
The stopApp call that we do in the SIGINT handler gets called and tries to issue an ext.flutter.exit call to the VM service to shutdown the running Flutter app on the device... but the VM service connection is dead so it never gets the shutdown call.
As a test, instead of starting iproxy directly, I patched the tool to start it through a wrapper script that traps and ignores SIGINT and everything ran nicely as expected.
Why doesn't this happen for Android? adb doesn't stay running as a child process, it starts its own daemon off to the side.
It's also possible to catch the SIGINT from the dart script and have some sort of orderly shutdown I would imagine? In any case, whatever you decide is fine. :) I recall we had to catch SIGINT in Webkit's python testing script (as KeyboardInterrupt) to do a bunch of orderly shutdown stuff.
Yep. I'll play around a bit with it and do some digging over the weekend to see what we can do. I've got a workaround, but it's a hack and there's almost certainly a simple, proper way to do this.
I'm not 100% convinced I'm right about iproxy getting the SIGINT. Something is definitely killing it, which is the source of the naughty behaviour, but in local testing with a contrived example, I see the expected behaviour of only the parent receiving SIGINT. Will try to get a clear picture of how we're killing it over the weekend and get a fix together.
Activity
[-]control-C does not exist app on iOS device from `flutter run`[/-][+]control-C does not exit app on iOS device from `flutter run`[/+]cbracken commentedon Mar 31, 2017
Instructions no longer include
ctrl-c to quit.Hixie commentedon Mar 31, 2017
Why doesn't ^C exit the process on Mac?
cbracken commentedon Apr 1, 2017
Just tested on Android and as you note, even though we don't make the promise anymore, there's a definite difference in behaviour. Re-opening.
Here's what appears to be going on. When the terminal receives ctrl-c, it sends
SIGINTto the processgroup. On iOS, one of the child processes of flutter tool isiproxy, which manages all the port forwarding we do -- in this case, that includes the observatory port forwarding.iproxygets SIGINT and dies, which kills our observatory connection.The
stopAppcall that we do in theSIGINThandler gets called and tries to issue anext.flutter.exitcall to the VM service to shutdown the running Flutter app on the device... but the VM service connection is dead so it never gets the shutdown call.As a test, instead of starting iproxy directly, I patched the tool to start it through a wrapper script that traps and ignores
SIGINTand everything ran nicely as expected.Why doesn't this happen for Android?
adbdoesn't stay running as a child process, it starts its own daemon off to the side.eseidelGoogle commentedon Apr 1, 2017
It's also possible to catch the SIGINT from the dart script and have some sort of orderly shutdown I would imagine? In any case, whatever you decide is fine. :) I recall we had to catch SIGINT in Webkit's python testing script (as KeyboardInterrupt) to do a bunch of orderly shutdown stuff.
Hixie commentedon Apr 1, 2017
We do catch it in the Dart script, but for some reason it also hits
iproxy.cbracken commentedon Apr 1, 2017
Yep. I'll play around a bit with it and do some digging over the weekend to see what we can do. I've got a workaround, but it's a hack and there's almost certainly a simple, proper way to do this.I'm not 100% convinced I'm right about
iproxygetting the SIGINT. Something is definitely killing it, which is the source of the naughty behaviour, but in local testing with a contrived example, I see the expected behaviour of only the parent receiving SIGINT. Will try to get a clear picture of how we're killing it over the weekend and get a fix together.3 remaining items