Closed Bug 612484 Opened 14 years ago Closed 14 years ago

Intermittent browser_overflowScroll.js | Test timed out

Categories

(Firefox :: Tabbed Browser, defect)

x86
Windows Server 2003
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 4.0b8

People

(Reporter: philor, Assigned: philor)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289868263.1289873363.5513.gz
WINNT 5.2 mozilla-central debug test mochitest-other on 2010/11/15 16:44:23
s: win32-slave17

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_overflowScroll.js | Test timed out
Attached patch Double timeoutSplinter Review
Its sort of interesting that this started timing out only on Windows debug at an unlikely time for it to start timing out, but not really interesting enough to keep watching it fail. Windows debug is slow, requestLongerTimeout can help.
Assignee: nobody → philringnalda
Status: NEW → ASSIGNED
Attachment #494323 - Flags: review?(dao)
Comment on attachment 494323 [details] [diff] [review]
Double timeout

The test takes 1.2 seconds on my netbook, so I don't think this makes sense.
Attachment #494323 - Flags: review?(dao) → review-
Comment on attachment 494323 [details] [diff] [review]
Double timeout

Sorry, I was more than a little too terse with just "Windows debug is slow," and led you to the wrong conclusion.

With opt builds, the tinderboxes take between 1 and 2 seconds for this test, making me wonder if maybe your netbook 1.2 seconds was with an opt build. If you ctrl+f, "opt" on this bug's page, you'll see it's only mentioned in this comment. Opt isn't the problem. With debug builds, for the most part tinderboxes take around 10 or 11 seconds for this test, with some exceptions.

There are three different sorts of Windows slaves:

* The Win7 tests are run on Mac minis with names starting with "talos-r3-w7" - ctrl+f for that in this bug's page will show that those are not a problem

* Sometimes Win2K3 tests are run on fast hardware slaves from iXsystems with names including "-ix-" - ctrl+f for that in this bug's page will show that those are not a problem

* The rest of the Win2K3 tests are run on miserably slow VMs that are the reason we started buying the iX slaves - those have names like "every single slave mentioned in this bug" :)

http://tbpl.mozilla.org/?tree=MozillaTry&rev=c6dcd71e28b0 is the results of my attempt, with nthomas' help, to catch an instance of this bug on the try server, with this patch plus some cheap Date.now() timing. I didn't quite manage to catch it, but my best/worst one in http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1291603726.1291609321.8515.gz&fulltext=1 came pretty darn close with "finished in 28599ms" and all of them had more in common with 30 seconds than with 1.2 seconds.

Practically speaking, there are four parts to this test:

* we open a resolution-dependent number of tabs, apparently 29 for Win2K3 at the tinderboxes' resolution (and probably fewer at your netbook's resolution), and we perf-test that since we're racing against the timeout

* we run the actual tests

* we perf-test running the actual tests, since we're still racing against the timeout, but I doubt they take much time, though I didn't instrument that part

* we perf-test closing all but one tab, since we're still racing against the timeout

In that worst-case run, just closing the tabs took 11778 milliseconds of the total 28599 milliseconds - 766ms to close the first three, then 1401ms to close the next one, and painfully on and on.

If you wanted to fix "Closing more than three tabs quickly in a Windows debug build is painfully slow" I'm pretty sure that the people who use them would be thrilled, but I would assert that leaving this test intermittently timing out and going orange because of that, rather than because of anything that it is testing, is not the way to go about it.
Attachment #494323 - Flags: review- → review?(dao)
Attachment #494323 - Flags: review?(dao) → review+
http://hg.mozilla.org/mozilla-central/rev/a99f870ea8b7

Not that I think anyone contemplating reopening an [orange] bug will actually read a comment (I never do), but:

* if you have a Windows debug timeout that happened after all the actual tests were finished, please reopen

* if you have any other OS, or opt Windows, or the timeout happened somewhere other than after all the tests were done, please file a new bug
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b8
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: