Closed Bug 1244978 Opened 8 years ago Closed 8 years ago

Intermittent test_value_storage.html | Test timed out.

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
ARM
Android
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla52
Tracking Flags:
Tracking Status
firefox51 --- fixed
firefox52 --- fixed

People

(Reporter: philor, Assigned: dholbert)

References

Details

(Keywords: intermittent-failure) 

+++ This bug was initially created as a clone of Bug #1238840 +++

+++ This bug was initially created as a clone of Bug #1073761 +++

https://treeherder.mozilla.org/logviewer.html#?job_id=20867422&repo=mozilla-inbound
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
:dholbert, I see you patched this test for android earlier this year in bug 1238840.  This is happening again, at a much higher rate as of this week- in fact we are at a rate to be in the top 5 intermittents.  Can you look at this again and determine if we need to split the test up, request a longer timeout, fix some other issue in the test/browser, or disable for android-debug?
Flags: needinfo?(dholbert)
That is a bit worrisome. It does indeed look like this started spiking this past Monday (reported 1 day later, in comment 9).  Before that, 10-40 failures per week. Now we're getting 15-28 failures per day.

I do expect we can fix this by increasing the requestLongerTimeout factor, as we did in bug 1238840.  But it might be worth trying to identify the reason for the recent increased rate, first...
I retriggered a bunch of mochitest runs, from inbound pushes that had hit this failure before & after it got bad. If it's frequent enough, hopefully the retriggers can validate good/bad classifications & help us narrow down when it regressed.

Current "last known good" candidate:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=4128e57e39bda4d6fe223e911906c81851d76e70
Current "first known bad" candidate:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=3e74d390dea4d3311b2eea00be094331dfe3f64f

(If those classifications are correct, the regression range at this point would be:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=4128e57e39bd&tochange=3e74d390dea4 )
(note to self: add &filter-searchStr=mochitest-25 to the end of those treeherder URLs to narrow in on the interesting bit)
Flags: needinfo?(dholbert)
Flags: needinfo?(dholbert)
Comment 13's "good" build was actually probably-bad. I gave it 20 runs of this test job, and half of them were orange (which was about the same ratio as the "Bad" build).  So, now I'm calling that one the "first known-bad".
Direct link to M-25 filtered version of that run:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=4128e57e39bda4d6fe223e911906c81851d76e70&filter-searchStr=mochitest-25

And here's a tentative maybe-good run from a few days previous:
https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=3898797a6267e6d0f84049258e261e207fafd4e5&filter-searchStr=mochitest-25
The regression bounds in comment 16 seem to be accurate. I'll see if I can get a narrower range. (Kinda slow going, as each run of this testsuite takes ~2 hours to complete.)

In the meantime, we might as well increment the requestLongerTimeout() count, since this was already failing enough to be annoying even before the recent regression -- so, I'll push a patch to do that.
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c0b400ac30a0
Increment the requestLongerTimeout() arg for mochitest test_value_storage.html, to avoid spurious timeouts on Android debug test-runs. (test-only, no review)
https://hg.mozilla.org/mozilla-central/rev/c0b400ac30a0
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox52: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
See Also: → 1317732
Blocks: 1318393
Assignee: nobody → dholbert
status-firefox51: --- → affected
Flags: needinfo?(dholbert)
You need to log in before you can comment on or make changes to this bug.