WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
36380
REGESSION: websocket/tests/frame-lengths.html times out on Tiger bot
https://bugs.webkit.org/show_bug.cgi?id=36380
Summary
REGESSION: websocket/tests/frame-lengths.html times out on Tiger bot
Eric Seidel (no email)
Reported
2010-03-19 12:06:22 PDT
REGESSION: websocket/tests/frame-lengths.html times out on Tiger bot This has been happening for days, if not weeks and has rendered the bot useless. We need to find resolution to this soon, even if that means skipping this test on tiger. Two recent failures:
http://build.webkit.org/results/Tiger%20Intel%20Release/r56247%20(9828)/websocket/tests/frame-lengths-diffs.txt
http://build.webkit.org/results/Tiger%20Intel%20Release/r56243%20(9825)/websocket/tests/frame-lengths-diffs.txt
This fails every Tiger build.
Attachments
proposed patch
(4.29 KB, patch)
2010-03-19 13:18 PDT
,
Alexey Proskuryakov
darin
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2010-03-19 12:08:44 PDT
This has been failing since at least 2/22/09:
https://bugs.webkit.org/show_bug.cgi?id=35041#c2
I think we should just skip this test on Tiger since it's been ignored for nearly a month already.
Eric Seidel (no email)
Comment 2
2010-03-19 12:17:32 PDT
This test was added by Alexey 3 months ago:
http://trac.webkit.org/browser/trunk/LayoutTests/websocket/tests/frame-lengths.html
Alexey Proskuryakov
Comment 3
2010-03-19 12:32:33 PDT
This test has always timed out on slow machines. I think that we need to increase the timeout.
Eric Seidel (no email)
Comment 4
2010-03-19 12:34:57 PDT
How do we do that?
Alexey Proskuryakov
Comment 5
2010-03-19 12:40:58 PDT
Just change these lines in run-webkit-tests, and make matching changes to DRT, I guess. # DumpRenderTree has an internal timeout of 15 seconds, so this must be > 15. my $timeoutSeconds = 20;
Eric Seidel (no email)
Comment 6
2010-03-19 12:43:09 PDT
That seems wrong. Why would we want to make all tests possibly take longer when timing out, instead of modifying this single test? new-run-webkit-tests has a way of marking a single test as slow, but we don't have that ability for run-webkit-tests yet. Seems we should either cut this test down to size or skip it on slow machines instead. No?
Alexey Proskuryakov
Comment 7
2010-03-19 13:03:07 PDT
I'd agree if only one test was timing out, but in fact, many tests are timing out on slower machines. Didn't we discuss this on webkit-dev a few days ago? How much of a problem would increasing the timeout be in practice? Normally, no tests are timing out, so such a change wouldn't affect anything.
Eric Seidel (no email)
Comment 8
2010-03-19 13:04:36 PDT
I must have missed the webkit-dev discussion. I reverse my position. r=me to increase the timeout. Once we have the new-webkit-tests technology of individual "slow tests", we can push the timeout back down.
Alexey Proskuryakov
Comment 9
2010-03-19 13:18:43 PDT
Created
attachment 51183
[details]
proposed patch
Alexey Proskuryakov
Comment 10
2010-03-19 13:20:48 PDT
***
Bug 35041
has been marked as a duplicate of this bug. ***
Eric Seidel (no email)
Comment 11
2010-03-19 13:22:10 PDT
A little trivia: new-webkit-tests's timeout limit is 6 seconds for release and 12 for debug. :) You can mark individual tests as SLOW and then they get 5X the base timeout.
Alexey Proskuryakov
Comment 12
2010-03-19 13:22:49 PDT
Committed revision 56262.
Alexey Proskuryakov
Comment 13
2010-03-19 13:24:03 PDT
> A little trivia:
Is there a global override? Running the tests on PPC/Debug, or on a mobile platform would be a pain without one.
Eric Seidel (no email)
Comment 14
2010-03-19 13:43:11 PDT
The architecture is such that one could have a per-port timeout. Although that's not currently wired up. You can also (already) pass a timeout over the command line. See: new-run-webkit-tests --help
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug