Obsolete
Status Update
No update yet.
Comments
mm...@gmail.com
I am running into the same problem running Flutter integration tests on an android emulator:
https://travis-ci.org/brianegan/flutter_architecture_samples/builds/517050722
The failing build is using:
Android emulator version 28.0.25.0 (build_id 5395263) (CL:77b96786ddf712e1477c6e05cddb09526043faef)
(https://travis-ci.org/brianegan/flutter_architecture_samples/jobs/517108854#L1102 )
... which fails to start while issuing the error message:
emulator: ERROR: detected a hanging thread 'QEMU1 main loop'. No response for 105001 ms
(https://travis-ci.org/brianegan/flutter_architecture_samples/jobs/517050724#L1284 )
By pinning the emulator as suggested by Pietro to:
Android emulator version 28.0.23.0 (build_id 5264690) (CL:be2be19ca0131957449e8c0ded5e55070f9537b0)
(https://travis-ci.org/brianegan/flutter_architecture_samples/jobs/517108854#L1121 )
... all the emulators start-up successfully and the jobs in the build succeed:
https://travis-ci.org/brianegan/flutter_architecture_samples/builds/517108852
The failing build is using:
Android emulator version 28.0.25.0 (build_id 5395263) (CL:77b96786ddf712e1477c6e05cddb09526043faef)
(
... which fails to start while issuing the error message:
emulator: ERROR: detected a hanging thread 'QEMU1 main loop'. No response for 105001 ms
(
By pinning the emulator as suggested by Pietro to:
Android emulator version 28.0.23.0 (build_id 5264690) (CL:be2be19ca0131957449e8c0ded5e55070f9537b0)
(
... all the emulators start-up successfully and the jobs in the build succeed:
rm...@google.com
Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.
lf...@google.com
Thanks for bringing this up. Was the emulator started from a snapshot? You might need to cold boot.
lf...@google.com
-gpu swiftshader_indirect also try that
lf...@google.com
Can we also run emulator with -verbose to see if there are any messages?
lf...@google.com
Also, would you be able to use the ARM system image with QEMU2? I see that we're using QEMU1 there. I think you'll need to just update the API 25 system image.
lf...@google.com
BTW, using hte x86 image doesn't necessarily mean you need to use KVM. Passing -no-accel in the command line turns KVM off if you are running on a setup without KVM.
pi...@pietroalbini.org
Thanks for digging into the issue!
> Was the emulator started from a snapshot?
No, the emulator is started fresh every time the container is booted.
> -gpu swiftshader_indirect also try that
The error message still appears.
> Can we also run emulator with -verbose to see if there are any messages?
Attached a build log with -verbose passed to the emulator (it's a bit noisy though).
> Also, would you be able to use the ARM system image with QEMU2?
We can't use QEMU2 on API 18 since it sets the current time to the epoch instead of the current time (as QEMU1 does), causing our test suite to fail.
> I think you'll need to just update the API 25 system image.
The package system-images;android-25;default;armeabi-v7a doesn't seem to exist.
> Passing -no-accel in the command line turns KVM off if you are running on a setup without KVM.
The error message still appears.
=========
By the way, here are some pointers on where to change things in the rust-lang/rust repo to debug the issue:
src/ci/docker/arm-android/Dockerfile: pinned versions are defined here
src/ci/docker/scripts/android-sdk.sh: sdk download and configuration code
src/ci/docker/scripts/android-start-emulator.sh: emulator startup flags
And as usual, to run the test suite:
src/ci/docker/run.sh arm-android
> Was the emulator started from a snapshot?
No, the emulator is started fresh every time the container is booted.
> -gpu swiftshader_indirect also try that
The error message still appears.
> Can we also run emulator with -verbose to see if there are any messages?
Attached a build log with -verbose passed to the emulator (it's a bit noisy though).
> Also, would you be able to use the ARM system image with QEMU2?
We can't use QEMU2 on API 18 since it sets the current time to the epoch instead of the current time (as QEMU1 does), causing our test suite to fail.
> I think you'll need to just update the API 25 system image.
The package system-images;android-25;default;armeabi-v7a doesn't seem to exist.
> Passing -no-accel in the command line turns KVM off if you are running on a setup without KVM.
The error message still appears.
=========
By the way, here are some pointers on where to change things in the rust-lang/rust repo to debug the issue:
src/ci/docker/arm-android/Dockerfile: pinned versions are defined here
src/ci/docker/scripts/android-sdk.sh: sdk download and configuration code
src/ci/docker/scripts/android-start-emulator.sh: emulator startup flags
And as usual, to run the test suite:
src/ci/docker/run.sh arm-android
lf...@google.com
Thanks for the repro steps. In the meantime, I wonder if it is because in 28.0.25 we used newer emulator/lib/pc-bios. Try replacing your 28.0.25's emulator/lib/pc-bios with the attached zip's contents.
Note that very soon, we will push 29.0.x to stable which removes support for qemu1. Are there any other system images you can run the tests on that do not require qemu1?
also try:
system-images;android-22;default;armeabi-v7a
Note that very soon, we will push 29.0.x to stable which removes support for qemu1. Are there any other system images you can run the tests on that do not require qemu1?
also try:
system-images;android-22;default;armeabi-v7a
pi...@pietroalbini.org
> Try replacing your 28.0.25's emulator/lib/pc-bios with the attached zip's contents.
The issue also happens with the replaced pc-bios.
I'll test qemu2/android-22 tomorrow.
Pietro.
The issue also happens with the replaced pc-bios.
I'll test qemu2/android-22 tomorrow.
Pietro.
mm...@gmail.com
FWIW: it looks like this is only happening on linux. The following macOS job ran with Android emulator version 28.0.25.0 without a problem:
https://travis-ci.com/mmcc007/screenshots/builds/107851257
Description
We have a fairly complex CI setup to test the Rust compiler on all the targets the support, and for Android we run the test suite inside the Android Emulator. All our CI is run inside a Docker image, and a few days ago we noticed freshly built images failed to run our test suite even with known good commits, showing an emulator error message that the QEMU main loop was hanging.
After digging the issue for a bit we noticed that the newer images contained the Android Emulator version 28.0.25, while the older (good) ones used version 28.0.23 of the emulator. After changing the Docker image to pin the good version of the emulator the bug went away.
We'd prefer not to pin the emulator, but we can't do the upgrade unless the bug is fixed. Any idea on what could have caused the problem?
Bug Template
============
Android Studio Version: none (we're experiencing this inside CI)
Emulator Version:
Android emulator version 28.0.25.0 (build_id 5395263) (CL:77b96786ddf712e1477c6e05cddb09526043faef)
Android SDK Tools: sdkmanager version 26.1.1
Host Operating System: Ubuntu 16.04 LTS inside Docker
CPU Manufacturer: Intel (builds are run on GCP through Travis CI)
Steps to Reproduce Bug
======================
Please note that these steps start a full CI build of the Rust compiler for the Android target. Everything should be contained inside the Docker image it spawns, but expect it to take a lot of disk space, CPU, RAM and time (on my local development machine it takes ~30 minuted before the bug shows up).
1. git clone
2. git checkout 4fb888bf04d2f1913e78e9eae51ac5695df1dc01
3. src/ci/docker/run.sh arm-android
Expected Behavior
=================
The build and tests are executed successfully inside the emulator.
Observed Behavior
=================
The build stops with this message:
emulator: ERROR: detected a hanging thread 'QEMU1 main loop'. No response for 105001 ms