Closed Bug 969612 Opened 6 years ago Closed 6 years ago
_URIs .js times out on Android 2 .3 emulator
xpcshell test test_URIs.js consistently times out on the Android 2.3 emulator. It runs fine (but is a long test) on Android 2.2 and Android 4.0. It appears to be the only xpcshell test that times out in the new environment. https://tbpl.mozilla.org/php/getParsedLog.php?id=34305627&tree=Ash&full=1 12:28:21 WARNING - TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_URIs.js | Test timed out ... 12:28:34 INFO - TEST-INFO | test_URIs.js | [do_test_uri_with_hash_suffix : 723] making sure caller is using suffix that starts with '#' 12:28:34 INFO - TEST-PASS | test_URIs.js | [do_test_uri_with_hash_suffix : 724] "#" == "#" 12:28:34 INFO - TEST-INFO | test_URIs.js | [do_test_uri_with_hash_suffix : 746] testing http://a/b/c/d;p?q with '#myRef#x:yz' appended equals a clone of itself 12:28:34 INFO - \x00 12:28:34 INFO - <<<<<<<
For now I just want to skip this test to get Android 2.3 xpcshell tests running green.
If I had to guess, I'd say this is just because this test does a ton of combinations of tests.
The Android 2.3 emulator has sdk level "10".
Comment on attachment 8373371 [details] [diff] [review] skip test_URIs on Android 2.3 Review of attachment 8373371 [details] [diff] [review]: ----------------------------------------------------------------- Glad you caught that!
Attachment #8373371 - Flags: review?(dminor) → review+
Is there a way to request (In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > If I had to guess, I'd say this is just because this test does a ton of > combinations of tests. Wow, yeah -- the size of its 'gTests' array has tripled since the last time I looked at this test. :) I guess that means we've got better coverage, which is good. Can we request a longer timeout for xpcshell tests, like we can for mochitests? (side-note: do the timestamps in xpcshell test logs map to reality at all? I don't understand how we can have things like: > 12:28:21 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_NetUtil.js | running test ... > 12:28:21 INFO - TEST-PASS | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_NetUtil.js | test passed (time: 10759.524ms) That "time: " suffix indicates that this other test took 10 seconds, and yet it started and completed at the same timestamp. (12:28:21) Are these timestamps just from a log post-processing step, and not from the actual test-running timeline?)
The timestamps at the beginning are from mozharness, so they're just getting the log whenever it comes out of the harness. There's almost certainly buffering involved.
I added a lot of tests to make sure we were actually testing all the options in URIs (back in 2011). Alternatively, this is fairly easily split into two tests and it won't add a lot of overhead.
Here's a simple follow up on your idea to split the test cases across two tests. I copied test_URIs.js to test_URIs2.js, removed roughly half of gTests from test_URIs.js and the remainder from test_URIs2.js, and added a couple of comments to guide future changes. They seem to run reliably on Android 2.3 now: https://tbpl.mozilla.org/php/getParsedLog.php?id=35158027&tree=Ash&full=1 11:38:36 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_URIs.js | running test ... 11:38:36 INFO - TEST-PASS | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_URIs.js | test passed (time: 151446.733ms) 11:38:36 INFO - TEST-INFO | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_URIs2.js | running test ... 11:38:36 INFO - TEST-PASS | /builds/slave/test/build/tests/xpcshell/tests/netwerk/test/unit/test_URIs2.js | test passed (time: 113990.488ms)
Attachment #8380819 - Flags: review?(rjesup)
Attachment #8380819 - Flags: review?(rjesup) → review+
Attachment #8373371 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.