Closed Bug 1325530 Opened 3 years ago Closed 2 years ago
_shown .js | This test exceeded the timeout threshold . It should be rewritten or split up . If that's not possible, use request Longer Timeout(N), but only as a last resort . -
Filed by: philringnalda [at] gmail.com https://treeherder.mozilla.org/logviewer.html#?job_id=8342249&repo=autoland https://archive.mozilla.org/pub/firefox/tinderbox-builds/autoland-linux-debug/1482428453/autoland_ubuntu32_vm-debug_test-mochitest-e10s-browser-chrome-7-bm142-tests1-linux32-build27.txt.gz
Well, that's upsetting. The spike of these failures that's going to be mentioned tonight started on the merge of this backout to autoland: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=de22d4444e76e5b8cdb80e772776d283210eaaf2&filter-searchStr=6af427563d6f0bdccde10a845b45a4a0fc23a359 https://treeherder.mozilla.org/#/jobs?repo=autoland&fromchange=3f27c55fa17fd02ec659235dc9ddbc03155e4f24&noautoclassify&filter-searchStr=6af427563d6f0bdccde10a845b45a4a0fc23a359&selectedJob=116133106&group_state=expanded
is this perma fail, can we back this out :KWierso?
Whiteboard: [stockwell needswork]
Not permafailing. I'd say it's about 50% failure rate. And I was wrong in comment 3. The chunk the test runs in keeps shifting, so it only looked like that backout merge caused the spike. I can try further tracking down where this started.
Actually, I would guess it'd be https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=653720e594d17796bf940e69933c8a712a4db38c&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=running&filter-resultStatus=pending&filter-resultStatus=runnable&filter-searchStr=linux32+debug+s(bc that caused this.
This was a long-running test before mconley's change: Test durations for browser/base/content/test/tabcrashed/browser_shown.js on mozilla-central,mozilla-inbound,autoland between 2017-07-11 and 2017-07-18 linux32/debug-e10s: 103.66 s (82.71 s - 123.08 s over 193 runs) linux32/opt-e10s: 24.69 s (20.94 s - 47.71 s over 231 runs) linux64/debug-e10s: 97.67 s (79.46 s - 138.65 s over 285 runs) With those durations, it seems odd that frequent failures were not reported earlier. Regardless, we have the standard options: Find a way to optimize or simplify the test, split it up into 2 or more tests, or requestLongerTimeout(). Hoping mconley has time to fix this soon...
The simplest "solution"! Also, I noticed https://dxr.mozilla.org/mozilla-central/rev/7d2e89fb92331d7e4296391213c1e63db628e046/browser/base/content/test/tabcrashed/browser_showForm.js#5 and other tabcrashed tests already requestLongerTimeout().
Attachment #8890021 - Flags: review?(mconley)
Comment on attachment 8890021 [details] [diff] [review] requestLongerTimeout Review of attachment 8890021 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!
Attachment #8890021 - Flags: review?(mconley) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/d0a02adc8689 requestLongerTimeout for browser_shown.js; r=mconley
Whiteboard: [stockwell needswork] → [stockwell fixed:timing]
You need to log in before you can comment on or make changes to this bug.