Open Bug 1235746 Opened 4 years ago Updated 3 years ago

|mach android-emulator| shuts down the emulator after a few minutes on Windows

Categories

(Testing :: General, defect)

x86_64
Windows 10
defect
Not set

Tracking

(firefox46 affected)

Tracking Status
firefox46 --- affected

People

(Reporter: Dexter, Unassigned)

Details

With bug 1235559, Windows devs are able to download and run Android emulators to debug/test Firefox for Android (which can be built in a linux VM).

Everything works just fine until, sadly, the emulator (4.3 image) gets shut down:

$ ./mach android-emulator --verbose --wait
DEBUG: Unable to find executable at
DEBUG: adb.exe found at C:\Users\Alessio\AppData\Local\Android\android-sdk\platform-tools\adb.exe
DEBUG: Emulator created with type 4.3
DEBUG: Unable to find executable at
DEBUG: emulator.exe found at C:\Users\Alessio\AppData\Local\Android\android-sdk\tools\emulator.exe
DEBUG: AVD found at c:/Users/Alessio\.mozbuild\android-device\avd\mozemulator-4.3.avd
 0:01.81 Starting Android emulator running Android 4.3...
DEBUG: Starting the emulator with this command: C:\Users\Alessio\AppData\Local\Android\android-sdk\tools\emulator.exe -avd mozemulator-4.3 -port 5554 -show-kernel -debug init,console,gles,memcheck,adbserver,adbclient,adb,avd_config,socket
DEBUG: Emulator output will be written to 'c:/Users/Alessio\.mozbuild\android-device\emulator.log'
DEBUG: Emulator started with pid 9936
DEBUG: Waiting for device status...
DEBUG: Device status verified.
DEBUG: Checking that Android has booted...
DEBUG: Android boot status verified.
DEBUG: >>> avd status
DEBUG: <<<
virtual device is running
OK
DEBUG: >>> redir list
DEBUG: <<<
no active redirections
OK
DEBUG: >>> network status
DEBUG: <<<
Current network status:
  download speed:          0 bits/s (0.0 KB/s)
  upload speed:            0 bits/s (0.0 KB/s)
  minimum latency:  0 ms
  maximum latency:  0 ms
OK
 0:43.35 Android emulator is running.
 0:43.35 No Firefox for Android build detected.
Switch to a Firefox for Android build context or use 'mach bootstrap'
to setup an Android build environment.
 0:43.35 Waiting for Android emulator to close...
Parent process 9936 exited with children alive:
PIDS: 7176
Attempting to kill them...
 4:56.37 Android emulator completed with return code 0.

Manually running the same command ./mach android-emulator generates works just fine.
:ahal -- Can you offer some insight? I think we are hitting http://hg.mozilla.org/mozilla-central/annotate/9ddf0da90fb3/testing/mozbase/mozprocess/mozprocess/processhandler.py#l393. |mach android-emulator --wait| is using mozprocess to launch and wait for "emulator.exe". I guess emulator.exe spawns a child and then exits, and mozprocess then kills the child after 3+ minutes. Is there a way to keep waiting (and not kill anything) until the child exits?
Flags: needinfo?(ahalberstadt)
(In reply to Geoff Brown [:gbrown] from comment #1)
> |mach android-emulator --wait| is using mozprocess to launch and wait for "emulator.exe". I guess
> emulator.exe spawns a child and then exits, and mozprocess then kills the
> child after 3+ minutes.

That's exactly what I'm seeing locally: "emulator.exe" spawns "emulator-arm.exe" and then exits.
I know very little about mozprocess on windows. Unfortunately my name is on the blame because I'm the one who copied mozbase from github to m-c, but I didn't write that code. Here's the real blame:
https://github.com/mozilla/mozbase-deprecated/blame/old-master/mozprocess/mozprocess/processhandler.py#L347

The only help I can offer beyond that is maybe ignore_children is getting set to True somehow? Or there was a fallback to ignoring children? See this comment:
https://dxr.mozilla.org/mozilla-central/source/testing/mozbase/mozprocess/mozprocess/processhandler.py#54
Flags: needinfo?(ahalberstadt)
(In reply to Andrew Halberstadt [:ahal] from comment #3)
> The only help I can offer beyond that is maybe ignore_children is getting
> set to True somehow? Or there was a fallback to ignoring children? See this
> comment:
> https://dxr.mozilla.org/mozilla-central/source/testing/mozbase/mozprocess/
> mozprocess/processhandler.py#54

Thanks for following up! Unfortunately that doesn't seem to be the case, ignore_children is False on my system when the whole thing shuts down.
As highlighted in comment 1, when the parent process quits (on Windows) we expect the children to quit as well [1]. If that doesn't happen we kill all the children spawned by the parent [2].

As far as I can tell, this is the correct behaviour with |ignore_children| [3] being False. It tracks the parent process and all its children, which are killed when the parent quits.

[1] - https://dxr.mozilla.org/mozilla-central/rev/21bf1af375c1fa8565ae3bb2e89bd1a0809363d4/testing/mozbase/mozprocess/mozprocess/processhandler.py#441
[2] - https://dxr.mozilla.org/mozilla-central/rev/21bf1af375c1fa8565ae3bb2e89bd1a0809363d4/testing/mozbase/mozprocess/mozprocess/processhandler.py#383
[3] - https://dxr.mozilla.org/mozilla-central/source/testing/mozbase/mozprocess/mozprocess/processhandler.py#54
That seems like possibly-reasonable behavior for mozprocess; I wouldn't want to change that for fear of inconveniencing some other mozprocess client.

Is --wait really required on Windows? I see that option as a nice-to-have in general. I'm tempted to say "if Windows and --wait: fail("Sorry, --wait is not supported on Windows.")
(In reply to Geoff Brown [:gbrown] from comment #6)
> Is --wait really required on Windows? I see that option as a nice-to-have in
> general. I'm tempted to say "if Windows and --wait: fail("Sorry, --wait is
> not supported on Windows.")

The problem is that the emulator shuts down also without "--wait", making it basically impossible to use for anything on Windows. I commonly use the emulator to track down issues with my XPCSHELL-tests: regardless of the presence of "--wait", the emulator gets killed while the xpcshell framework is still copying data over.

I had some success by adding |ignore_children=True| to [1] (only on Windows). I'm not sure if there's any implication, but works for me.

That said, I would second your temptation of clearly saying "--wait" isn't supported on Windows.

[1] - https://dxr.mozilla.org/mozilla-central/rev/21bf1af375c1fa8565ae3bb2e89bd1a0809363d4/testing/mozbase/mozrunner/mozrunner/devices/android_device.py#386
You need to log in before you can comment on or make changes to this bug.