Closed Bug 927602 Opened 6 years ago Closed 4 years ago

Android x86 mochitest-1 DMError: Automation Error: Timeout in command activity

Categories

(Testing :: General, defect)

x86
Android
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX
mozilla29

People

(Reporter: gbrown, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=28950392&tree=Ash&full=1

On Ash and Cedar, mochitest-gl (in S8) consistently fails with:

14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/runtests.py", line 1005, in runTests
14:11:19     INFO -     onLaunch=onLaunch
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/runtestsremote.py", line 542, in runApp
14:11:19     INFO -     return self._automation.runApp(*args, **kwargs)
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/automation.py", line 893, in runApp
14:11:19     INFO -     status = self.waitForFinish(proc, utilityPath, timeout, maxTime, startTime, debuggerInfo, symbolsPath)
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/remoteautomation.py", line 74, in waitForFinish
14:11:19     INFO -     status = proc.wait(timeout = maxTime)
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/remoteautomation.py", line 297, in wait
14:11:19     INFO -     while (self.dm.getTopActivity() == self.procName):
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/droid.py", line 154, in getTopActivity
14:11:19     INFO -     return self._runCmds([{ 'cmd': "activity" }]).strip()
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/devicemanagerSUT.py", line 152, in _runCmds
14:11:19     INFO -     self._sendCmds(cmdlist, outputfile, timeout, retryLimit=retryLimit)
14:11:19     INFO -   File "/builds/slave/talos-slave/test/build/tests/mochitest/devicemanagerSUT.py", line 134, in _sendCmds
14:11:19     INFO -     raise err
14:11:19     INFO - DMError: Automation Error: Timeout in command activity

Have we crashed the emulator, or has sutagent been killed (OOM), or...?

Curiously, if I copy the runtestsremote.py command line from a Cedar log and run that on a loaner ix box, the tests consistently succeed.

/builds/slave/talos-slave/test/build/venv/bin/python /builds/slave/talos-slave/test/build/tests/mochitest/runtestsremote.py --autorun --close-when-done --dm_trans=sut --console-level=INFO --app=org.mozilla.fennec --remote-webserver=10.0.2.2 --xre-path=/builds/slave/talos-slave/test/build/hostutils/xre --utility-path=/builds/slave/talos-slave/test/build/hostutils/bin --deviceIP=127.0.0.1 --devicePort=20703 --http-port=8856 --ssl-port=4456 --certificate-path=/builds/slave/talos-slave/test/build/tests/certs --symbols-path=http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/ash-android-x86/1381433268/fennec-27.0a1.en-US.android-i386.crashreporter-symbols.zip --test-path content/canvas/test/webgl
Armen -- can you have a look at this?
Flags: needinfo?(armenzg)
I will evaluate it tomorrow and come back to you before EOW.
Assignee: nobody → armenzg
Flags: needinfo?(armenzg)
I can't see anything relevant with that log.

I'm re-triggering a job since I hope that the buildbot log will have a little bit of more information or even be able to VNC into the machine.

If that doesn't work, I will try running it manually and see if I noticed anything differently.
It seems we have been having the issue since at least Sep. 19th:
https://tbpl.mozilla.org/php/getParsedLog.php?id=28113168&tree=Ash&full=1#error10
gbrown: would you please be able to remind me how to run this manually without mozharness?
I don't know if I'm doing it right.
My technique:

 - Use mozharness to run a test (any test really) normally. This will install Fennec, etc in the emulator environment.
 - Either keep the emulator running from the mozharness test (avoid the stop), or start an emulator again.
 - Run runtestsremote.py; my command line on the loaner:

/home/cltbld/tests/scripts/scripts/build/venv/bin/python /home/cltbld/tests/scripts/scripts/build/tests/mochitest/runtestsremote.py --autorun --close-when-done --dm_trans=sut --console-level=INFO --app=org.mozilla.fennec --remote-webserver=10.0.2.2 --xre-path=/home/cltbld/tests/scripts/scripts/build/hostutils/xre --utility-path=/home/cltbld/tests/scripts/scripts/build/hostutils/bin --deviceIP=127.0.0.1 --devicePort=20701 --http-port=8856 --ssl-port=4456 --certificate-path=/home/cltbld/tests/scripts/scripts/build/tests/certs --symbols-path=http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/ash-android-x86/1381433268/fennec-27.0a1.en-US.android-i386.crashreporter-symbols.zip --test-path content/canvas/test/webgl &> gl-out
I didn't make much progress on this since I focused on bug 919812 instead.
Assignee: armenzg → nobody
Blocks: 936226
Duplicate of this bug: 919784
mochitest-gl results were not shown on Cedar for a while because of bug 939823, but now we can confirm that the problem persists.

https://tbpl.mozilla.org/php/getParsedLog.php?id=31100923&tree=Cedar&full=1
https://tbpl.mozilla.org/php/getParsedLog.php?id=31105550&tree=Cedar&full=1
https://tbpl.mozilla.org/php/getParsedLog.php?id=31107419&tree=Cedar&full=1

I still cannot reproduce the problem on the ix loaner -- troubling.
Assignee: nobody → gbrown
I have tried to avoid this error by skipping various m-gl tests, but the problem persists: https://tbpl.mozilla.org/?tree=Cedar&showall=1&rev=853f59198933
I finally reproduced this problem on the ix loaner by using mozharness exactly as used on cedar.

Comparing the working/non-working cases on the loaner, I eventually found this curious result: the emulator typically crashes during mochitest-gl if the emulator is started with "-debug all"; it does not crash and the test typically succeeds if the emulator is started without the debug argument.

Unfortunately, if I remove "-debug all", the emulator crashes while running mochitest-2!
This already happens (infrequently) on other jobs:

mochitest-1: https://tbpl.mozilla.org/php/getParsedLog.php?id=31238275&tree=Cedar&full=1
In bug 944832, we started reporting the emulator output, and changed "-debug all" to "-debug <certain tags>". Following that change, mochitest-gl no longer reports "Timeout in command activity", but m1 sometimes does:

mochitest-1: https://tbpl.mozilla.org/php/getParsedLog.php?id=31387913&tree=Cedar&full=1
Summary: Android x86 mochitest-gl DMError: Automation Error: Timeout in command activity → Android x86 mochitest-1 DMError: Automation Error: Timeout in command activity
Observing these errors on the loaner, I see:
 - the emulator process is still running at the end of the job
 - "adb devices" sometimes shows "device" for all running emulators; sometimes it shows only some of the emulators (no output reported for the "missing" emulator(s))
 - telnet to the sut port fails
Now the logs show this condition more explicitly due to bug 946908.
I have been trying to reproduce this on the loaner with the mozharness improvements from bug 944832 and bug 946908 + "adb logcat > log &". Perhaps predictably, the failure occurs less frequently with all this logging. 

I finally got a logcat for a failure in jsreftest, but I see nothing amiss. It ends with:

12-06 18:33:56.114 I/GeckoDump( 1927): 11.1.1 The this keyword
12-06 18:33:56.134 E/GeckoConsole( 1927): [JavaScript Warning: "An unbalanced tree was written using document.write() causing data from the network to be reparsed. For more information https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing" {file: "http://10.0.2.2:8856/jsreftest/tests/jsreftest.html?test=ecma/Expressions/11.1.1.js" line: 15}]
12-06 18:33:56.134 E/GeckoConsole( 1927): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://10.0.2.2:8856/jsreftest/tests/jsreftest.html?test=ecma/Expressions/11.1.1.js" line: 0}]
12-06 18:33:56.144 E/GeckoConsole( 1927): [JavaScript Warning: "Use of Mutation Events is deprecated. Use MutationObserver instead." {file: "chrome://reftest/content/reftest-content.js" line: 471}]
12-06 18:33:56.245 D/dalvikvm( 1927): GC_CONCURRENT freed 388K, 8% free 5393K/5856K, paused 9ms+3ms, total 23ms
12-06 18:33:56.404 I/GeckoDump( 1927): 11.10-1 Binary Bitwise Operators:  &
12-06 18:33:56.414 E/GeckoConsole( 1927): [JavaScript Warning: "An unbalanced tree was written using document.write() causing data from the network to be reparsed. For more information https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing" {file: "http://10.0.2.2:8856/jsreftest/tests/jsreftest.html?test=ecma/Expressions/11.10-1.js" line: 15}]
12-06 18:33:56.414 E/GeckoConsole( 1927): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://10.0.2.2:8856/jsreftest/tests/jsreftest.html?test=ecma/Expressions/11.10-1.js" line: 0}]
12-06 18:33:56.424 E/GeckoConsole( 1927): [JavaScript Warning: "Use of Mutation Events is deprecated. Use MutationObserver instead." {file: "chrome://reftest/content/reftest-content.js" line: 471}]
12-06 18:33:56.594 D/dalvikvm( 1927): GC_CONCURRENT freed 380K, 8% free 5397K/5856K, paused 5ms+1ms, total 9ms
12-06 18:33:56.675 I/GeckoDump( 1927): 11.10-2 Binary Bitwise Operators:  |
12-06 18:33:56.775 E/GeckoConsole( 1927): [JavaScript Warning: "An unbalanced tree was written using document.write() causing data from the network to be reparsed. For more information https://developer.mozilla.org/en/Optimizing_Your_Pages_for_Speculative_Parsing" {file: "http://10.0.2.2:8856/jsreftest/tests/jsreftest.html?test=ecma/Expressions/11.10-2.js" line: 15}]
12-06 18:33:56.795 E/GeckoConsole( 1927): [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "http://10.0.2.2:8856/jsreftest/tests/jsreftest.html?test=ecma/Expressions/11.10-2.js" line: 0}]
12-06 18:33:56.795 E/GeckoConsole( 1927): [JavaScript Warning: "Use of Mutation Events is deprecated. Use MutationObserver instead." {file: "chrome://reftest/content/reftest-content.js" line: 471}]
12-06 18:33:57.104 D/dalvikvm( 1927): GC_CONCURRENT freed 383K, 8% free 5398K/5856K, paused 0ms+0ms, total 5m
Of course, the same error - "Timeout in command ..." - happens intermittently on tegras and pandas, in mochitest, jsreftest, and robocop, and has been happening for years (bug 807230). It seems to happen more often on Android x86...but maybe it just seems that way because so many jobs are consolidated on x86?
(In reply to Geoff Brown [:gbrown] from comment #16)
> I finally got a logcat for a failure in jsreftest, but I see nothing amiss.

I have reproduced the failure several times in jsreftest and mochitest-1, with full logcat, and this result is typical: logcat shows tests running, and then ends. In particular:
 - no sign of any processes terminating
 - no low memory messages
 - no ANR messages
 - only one CmdWorkerThread spawned by sutagent, as expected
 - typical sutagent output, indicating periodic activity, isdir, etc commands, as expected.
When this happens, adb shell hangs also. Here is the adb output with adb debugging enabled (ADB_TRACE=all):

[cltbld@talos-linux64-ix-001.test.releng.scl3.mozilla.com ~]$ adb -s emulator-5554 shell
system/core/adb/adb.c::main():Handling commandline()
system/core/adb/commandline.c::adb_commandline():starting interactive shell
system/core/adb/adb_client.c::_adb_connect():_adb_connect: host:version
system/core/adb/transport.c::writex():writex: fd=3 len=4: 30303063 000c
system/core/adb/transport.c::writex():writex: fd=3 len=12: 686f73743a76657273696f6e host:version
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
4f4b4159 OKAY
system/core/adb/adb_client.c::_adb_connect():_adb_connect: return fd 3
system/core/adb/adb_client.c::adb_connect():adb_connect: service shell:
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
30303034 0004
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
30303166 001f
system/core/adb/adb_client.c::_adb_connect():_adb_connect: shell:
system/core/adb/transport.c::writex():writex: fd=3 len=4: 30303163 001c
system/core/adb/transport.c::writex():writex: fd=3 len=28: 686f73743a7472616e73706f72743a65 host:transport:e
system/core/adb/adb_client.c::switch_socket_transport():Switch transport in progress
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
4f4b4159 OKAY
system/core/adb/adb_client.c::switch_socket_transport():Switch transport success
system/core/adb/transport.c::writex():writex: fd=3 len=4: 30303036 0006
system/core/adb/transport.c::writex():writex: fd=3 len=6: 7368656c6c3a shell:
system/core/adb/transport.c::readx():readx: fd=3 wanted=4


^C

I don't know what any of that really means, but here is the corresponding output for a healthy emulator:

[cltbld@talos-linux64-ix-001.test.releng.scl3.mozilla.com ~]$ adb -s emulator-5556 shell
system/core/adb/adb.c::main():Handling commandline()
system/core/adb/commandline.c::adb_commandline():starting interactive shell
system/core/adb/adb_client.c::_adb_connect():_adb_connect: host:version
system/core/adb/transport.c::writex():writex: fd=3 len=4: 30303063 000c
system/core/adb/transport.c::writex():writex: fd=3 len=12: 686f73743a76657273696f6e host:version
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
4f4b4159 OKAY
system/core/adb/adb_client.c::_adb_connect():_adb_connect: return fd 3
system/core/adb/adb_client.c::adb_connect():adb_connect: service shell:
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
30303034 0004
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
30303166 001f
system/core/adb/adb_client.c::_adb_connect():_adb_connect: shell:
system/core/adb/transport.c::writex():writex: fd=3 len=4: 30303163 001c
system/core/adb/transport.c::writex():writex: fd=3 len=28: 686f73743a7472616e73706f72743a65 host:transport:e
system/core/adb/adb_client.c::switch_socket_transport():Switch transport in progress
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
4f4b4159 OKAY
system/core/adb/adb_client.c::switch_socket_transport():Switch transport success
system/core/adb/transport.c::writex():writex: fd=3 len=4: 30303036 0006
system/core/adb/transport.c::writex():writex: fd=3 len=6: 7368656c6c3a shell:
system/core/adb/transport.c::readx():readx: fd=3 wanted=4
system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4
4f4b4159 OKAY
system/core/adb/adb_client.c::_adb_connect():_adb_connect: return fd 3
system/core/adb/adb_client.c::adb_connect():adb_connect: return fd 3
system/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): pre unix_read(fdi=0,...)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=17
root@android:/ # system/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): post unix_read(fdi=0,...)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): pre unix_read(fdi=0,...)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=1
esystem/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): post unix_read(fdi=0,...)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): pre unix_read(fdi=0,...)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=1
xsystem/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): post unix_read(fdi=0,...)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): pre unix_read(fdi=0,...)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=1
isystem/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): post unix_read(fdi=0,...)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): pre unix_read(fdi=0,...)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=1
tsystem/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): post unix_read(fdi=0,...)
system/core/adb/commandline.c::stdin_read_thread():stdin_read_thread(): pre unix_read(fdi=0,...)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=1
system/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=2

system/core/adb/commandline.c::read_and_dump():read_and_dump(): pre adb_read(fd=3)
system/core/adb/commandline.c::read_and_dump():read_and_dump(): post adb_read(fd=3): len=0
[cltbld@talos-linux64-ix-001.test.releng.scl3.mozilla.com ~]$
This bug remains my greatest concern, blocking running of Android x86 tests on trunk trees.

I mentioned this bug at the Mobile Testing meeting last week and :wlach asked if this loss of connectivity to the emulator ever occurs if tests are not running. That is, if the emulator runs by itself for a long time, without tests, does it remain stable and responsive? It does.

Jumping ahead a couple of steps, it seems to me that robocop and xpcshell tests never encounter this loss of connectivity. See the long line of green S4 (except for a few cases of bug 949740) at https://tbpl.mozilla.org/?tree=Cedar&showall=1&rev=5dc615915eb6, for instance.

What is different between {robocop, xpcshell} vs {reftests, mochitests}?
 - less logcat and test logging for {robocop, xpcshell}
 - fewer network connections from device to httpd.js for {robocop, xpcshell}
 - less sustained cpu load for {robocop, xpcshell}
 - ...

This suggests some additional experiments.
In experiments on the loaner, I stumbled on a very low frequency cause of these errors: Not waiting for sutagent startup correctly. In a rare case, our telnet-to-sut code may get an unexpected response and continue with a warning, allowing the tests to start before the sutagent has started. In this case, our initial devicemanager operation may timeout, or the socket connection may fail to be established.
In experiments on the loaner, I tried to determine if running js-reftests in smaller chunks would help. Results:

All js-reftests as one chunk: 25% of runs fail as described in this bug
Split into 3 chunks: 10% of runs fail
Split into 8 chunks: 10% of runs fail

(Note that chunking js-reftests is not very effective: At 8 chunks, 80% of assertions occur in the first chunk, and the first chunk seems more prone to this type of failure.)
Comment on attachment 8350171 [details] [diff] [review]
(1) improve wait for sutagent

See Comment 21.
Attachment #8350171 - Attachment description: improve wait for sutagent → (1) improve wait for sutagent
Attachment #8350171 - Flags: review?(armenzg)
Attachment #8350171 - Flags: review?(armenzg) → review+
Comment on attachment 8350171 [details] [diff] [review]
(1) improve wait for sutagent

Review of attachment 8350171 [details] [diff] [review]:
-----------------------------------------------------------------

::: scripts/android_emulator_unittest.py
@@ +219,3 @@
>              if attempts != 0:
>                 self.info("Sleeping 30 seconds")
>                 time.sleep(30)

Just a drive by comment: isn't 30 seconds kind of long to wait in between attempts? There should be no harm in checking every second or so, we do this for example with marionette:

http://mxr.mozilla.org/mozilla-central/source/testing/marionette/client/marionette/marionette.py#551
Now that you mention it, 30 seconds is a long time. I'll try shortenting it.

For now, landing patch as-is:

https://hg.mozilla.org/build/mozharness/rev/155fb7e0bc4f
Merged mozharness.
In experiments on the loaner, I tried to determine if reducing logging (as shown here https://tbpl.mozilla.org/?tree=Try&rev=1cba81397f25) would affect the S1 failure rate. Results:

Normal logging: 10% of runs fail (all jsr)
Reduced logging: 10% of runs fail (all jsr)
(In reply to Geoff Brown [:gbrown] from comment #20)
> it seems to me that robocop and xpcshell
> tests never encounter this loss of connectivity. 

Set S4 - Robocop and xpcshell tests - has been running on trunk for more than a week and there have been no reports of this type of error. In contrast, on Cedar, we continue to see occasional (~1 run in 10) loss of emulator connectivity failures in M-1, M-2, M-gl, JSR, and R-2.
But the R-2 failures are more consistent! In contrast to the JSR case (Comment 28), reviews of the full logcats show that the R-2 failures - which appear random in the main test log - always occur during one test, synthetic-bold-2.html.

https://tbpl.mozilla.org/php/getParsedLog.php?id=33673922&tree=Cedar&full=1
https://tbpl.mozilla.org/php/getParsedLog.php?id=33673909&tree=Cedar&full=1
https://tbpl.mozilla.org/php/getParsedLog.php?id=33674890&tree=Cedar&full=1
See Comment 30. 

https://tbpl.mozilla.org/?tree=Cedar&rev=66c80d0d4638 suggests that this significantly improves the reliability of R-2.
Attachment #8367345 - Flags: review?(dminor)
Comment on attachment 8367345 [details] [diff] [review]
(2) skip synthetic-bold-2.html on Android x86

I spoke too soon. Retries show this change is ineffective.
Attachment #8367345 - Flags: review?(dminor)
Attachment #8367688 - Flags: review?(dminor) → review+
Another approach for resolving the remaining errors of this type is to investigate the root cause of the reftest failures: What is it about font-stretch-1.html that sometimes causes the emulator to become unresponsive to adb and sut?
https://hg.mozilla.org/mozilla-central/rev/df55b667600a
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
Sorry, should have marked this [leave open].
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'm not finding time for this and x86 testing is not currently a high priority. Leaving open to one day determine and address root cause, and re-enable disabled tests.
Assignee: gbrown → nobody
Insufficient interest in running mochitest on x86.
Status: REOPENED → RESOLVED
Closed: 6 years ago4 years ago
Resolution: --- → WONTFIX
(In reply to Geoff Brown [:gbrown] from comment #39)
> Insufficient interest in running mochitest on x86.

Wait... so right now, we're left in a state where the tests here are marked "skip-if(Android)" with a reference to this bug.

Is that annotation still accurate/necessary?  If this was x86-specific (as it seems it was) and we're not running mochitests on Android x86, can we remove the annotation?
Flags: needinfo?(gbrown)
Sorry - comment 40 was actually in reference to the changes from patch (2) here ( https://hg.mozilla.org/mozilla-central/rev/df55b667600a ), which are technically reftests, not mochitests.

I take it comment 39 applied to reftests as well, though?
That's right: We are not running Android x86 reftests either. I should have backed out the skip-if landed in comment 36, or changed the bug reference before closing this bug. 

Let's see what we can do now: https://treeherder.mozilla.org/#/jobs?repo=try&revision=07c6db0a405b4224f9179493cc071bd20cfe7ad3.
Thanks!

If you don't mind, perhaps hold off on landing anything until bug 1307332's patches have landed (hopefully within the next day or two), to avoid causing more bitrot than is necessary for the monster pile of changes there.

(That bug's patches are removing all B2G/Mulet references in reftest.list, including on this line.)
Those test passed on try, so I'll enable them once bug 1307332 is resolved. Thanks dholbert - glad you noticed this!
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/558c51ec19e9
Enable skipped font-matching reftests on Android; r=me
Flags: needinfo?(gbrown)
You need to log in before you can comment on or make changes to this bug.