Closed Bug 1236414 Opened 9 years ago Closed 9 years ago

Intermittent e10s browser_crashedTabs.js | This test exceeded the timeout threshold. It should be rewritten or split up.

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 47
Tracking Flags:
Tracking Status
e10s + ---
firefox45 --- wontfix
firefox46 --- fixed
firefox47 --- fixed
firefox-esr45 --- unaffected

People

(Reporter: philor, Assigned: mconley)

References

(Blocks 1 open bug)

Details

(Keywords: intermittent-failure)

Summary: Intermittent browser_crashedTabs.js | This test exceeded the timeout threshold. It should be rewritten or split up. → Intermittent e10s browser_crashedTabs.js | This test exceeded the timeout threshold. It should be rewritten or split up.
Blocks: e10s-tests
tracking-e10s: --- → +
David, do you have any thoughts on this one? It seems to have increased in frequency at the end of January.
Flags: needinfo?(dteller)
I looked at it quickly, but that doesn't ring any bell. On the other hand, I don't know how that test is expected to work. mconley, do you know more?
Flags: needinfo?(dteller) → needinfo?(mconley)
Well, let's investigate that in try pushes which reenable it - a bit of retriggering says the failure rate is somewhere between 1/3 on Linux64 and 2/3 on Linux32, which is just teeny bit more than the absolute minimum acceptable standard, no matter how you calculate that 5%/1% thing in https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy#Low_intermittent_failure_rate
Keywords: leave-open
Whiteboard: [test disabled]
Note that, at least as far as I can tell, these timeouts occur on debug builds. If I had to guess, I'd say that gathering stacks and printing them out (as debug builds tend to do) might be slowing the test down and causing the timeout. Perhaps disabling it wholesale is too big a hammer - perhaps we should just disable it for debug builds? Philor, what do you think?
Flags: needinfo?(mconley) → needinfo?(philringnalda)
And since we're running e10s bc on Win7 opt and Win8 opt and debug and not failing there, you could just make it linux && debug. Or, since despite the failure message saying "use requestLongerTimeout(N), but only as a last resort" we actually use that as our first resort for exceeded timeout threshold, you could just increase it, push that and a reenable to try, figure out what chunk it runs in for opt linux and linux 64 and opt win7 and opt and debug win8 and retrigger them 25 times as well to be sure there's no other frequent failure in it while using retriggers of debug linux to check the timeout, and reenable it everywhere.
Flags: needinfo?(philringnalda)
ni'ing myself to try just boosting the test timeout.
Flags: needinfo?(mconley)
Hey philor, are the above try results compelling? Bumping the requestLongerTimeout to 10 in browser_crashedTabs.js seemed to do the job. Or would you like to see more retriggers?
Flags: needinfo?(mconley) → needinfo?(philringnalda)
More than enough to convince me: despite my usual hyperbole, I was being literal about 2/3 on Linux32, so you would have had me at three green in a row.
Flags: needinfo?(philringnalda)
No failures on trunk since it was re-enabled. https://hg.mozilla.org/releases/mozilla-aurora/rev/a27e36b00f9b
Assignee: nobody → mconley
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox45: affected → wontfix
status-firefox46: affected → fixed
status-firefox47: --- → fixed
status-firefox-esr45: --- → unaffected
Keywords: leave-open
Resolution: --- → FIXED
Whiteboard: [test disabled]
Target Milestone: --- → Firefox 47
You need to log in before you can comment on or make changes to this bug.