Bug 33256 - REGRESSION(52854?) fast/workers/shared-worker-constructor.html failed on Leopard Build Bot
Summary: REGRESSION(52854?) fast/workers/shared-worker-constructor.html failed on Leop...
Status: RESOLVED DUPLICATE of bug 33279
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P1 Normal
Assignee: Nobody
Depends on:
Reported: 2010-01-06 09:33 PST by Eric Seidel (no email)
Modified: 2010-01-29 13:56 PST (History)
9 users (show)

See Also:

Set isHttpdOpen to 0 if pidfile does not exist for some reason. (1.09 KB, patch)
2010-01-06 13:18 PST, Andras Becsi
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2010-01-06 09:33:48 PST
REGRESSION(52854?) fast/workers/shared-worker-constructor.html failed on Leopard Build Bot

The buildbot seems to think that r52854 was at fault, but I don't believe it:

Maybe the builds are failing to update on the test machine?
Comment 1 Eric Seidel (no email) 2010-01-06 09:35:03 PST
CCing Mark in case he knows of something going wrong with the bots.
Comment 2 Eric Seidel (no email) 2010-01-06 09:36:16 PST
Andrew added the test 4 months ago.
Comment 3 David Levin 2010-01-06 10:35:06 PST
It looks like it only happens on release builds. It happens for shared-worker-constructor.html on leopard and dedicated-worker-constructor.html on snow leopard -- both release builds.

I'll see if I can repro this.
Comment 4 Andrew Wilson 2010-01-06 10:37:55 PST
I'm guessing that the console error triggering this (Unexpected response
code:HTML) is coming from the *previous* test (websocket-event-target.html).

(dedicated-worker-lifecycle.html is disabled on leopard which is why we get the error on different tests on different builds).
Comment 5 Eric Seidel (no email) 2010-01-06 10:42:03 PST
http://trac.webkit.org/changeset/49488 added websocket-event-target.html (3 months ago).  I suspect there was some recent change to trigger this since it seems to be failing consistently.
Comment 6 Eric Seidel (no email) 2010-01-06 10:44:13 PST
I wonder if the previous change http://trac.webkit.org/changeset/52853 could be related.  That at least changed run-webkit-tests...
Comment 7 David Levin 2010-01-06 11:06:27 PST
I'm currently unable to repro this locally (when running all tests using a retail build after sync'ing to the latest revision).
Comment 8 Andras Becsi 2010-01-06 13:18:56 PST
Created attachment 45985 [details]
Set isHttpdOpen to 0 if pidfile does not exist for some reason.

This could maybe fix the test. It at least fixes:
"http/tests/appcache .(48)Address already in use: make_sock: could not bind to address
no listening sockets available, shutting down
Unable to open logs"

Which the log of the Leopard bot shows.

I do not understand how the pidfile could dissapear, but it more logical to set isHttpdOpen to 0.
Comment 9 Eric Seidel (no email) 2010-01-06 13:21:46 PST
I am not well enough versed in run-webkit-tests to know if this is correct.

Mark Rowe is probably your best bet for review.  It's possible that Adam Roben (because he's also hacked on RWT) or Alexey (because he's done so much httpd related testing) might know this code.
Comment 10 WebKit Review Bot 2010-01-06 13:22:17 PST
style-queue ran check-webkit-style on attachment 45985 [details] without any errors.
Comment 11 Eric Seidel (no email) 2010-01-06 14:11:32 PST
The commit-queue isn't much use to us for regression fixes.  It blocks itself while the bots are red so it doesn't ever make a red tree redder.   I should make it smarter to be able to ignore the bot status when landing a REGRESSION fix.  Maybe.
Comment 12 Eric Seidel (no email) 2010-01-06 14:11:44 PST
I'll land this by hand.
Comment 13 Eric Seidel (no email) 2010-01-06 14:12:55 PST
Comment on attachment 45985 [details]
Set isHttpdOpen to 0 if pidfile does not exist for some reason.

Clearing flags on attachment: 45985

Committed r52869: <http://trac.webkit.org/changeset/52869>
Comment 14 Eric Seidel (no email) 2010-01-06 14:13:03 PST
All reviewed patches have been landed.  Closing bug.
Comment 15 Eric Seidel (no email) 2010-01-06 14:41:52 PST
This does not seem to have fixed the problem:
Comment 16 Eric Seidel (no email) 2010-01-06 15:25:50 PST
Looks like:
http/tests/appcache .(48)Address already in use: make_sock: could not bind to address
no listening sockets available, shutting down
is still occuring in
which corresponds to r52870.

I'm not sure what to do other than to roll out the original change.  It seems futile to try and debug this on the bots.
Comment 17 Eric Seidel (no email) 2010-01-06 15:37:35 PST
I saw this failure trying to run-webkit-tests locally:

Timed out waiting for httpd to start at WebKitTools/Scripts/run-webkit-tests line 1425, <IN> line 37668.
Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--quiet']" exit_code: 60
Comment 18 Eric Seidel (no email) 2010-01-06 15:49:12 PST
I think that run-webkit-tests is not terminating the httpd processes correctly.  So even once I roll this out, I'm not sure it will fix the bots as they may have rogue httpd processes running.
Comment 19 Eric Seidel (no email) 2010-01-06 15:56:24 PST
Committed r52876: <http://trac.webkit.org/changeset/52876>
Comment 20 Eric Seidel (no email) 2010-01-06 16:14:19 PST
This does not seem to be my day.

The rollout did not fix the SL bot:
The Leopard bot is still building.

The first revision we saw this was r52854
but it is my suspicion that the revision was unrelated.
Comment 21 Eric Seidel (no email) 2010-01-06 16:28:03 PST
Despite this rollout not fixing the bots, my local run-webkit-tests httpd failure is now gone, so it is my suspicion that this change was at least related to my local failure if not the bot errors.

Leopard completed and is also failing:

Time for further debugging.  I guess we should just skip this test if we can't figure out what is wrong here.

I don't see any commits which could be related to this failure within 10 hours of when it first occurred.  I stopped searching after that point.
Comment 22 Eric Seidel (no email) 2010-01-06 16:32:53 PST
Andrew Wilson is right.  The log must be coming  from the previous test as it would come from this line of code:
Comment 23 Eric Seidel (no email) 2010-01-06 16:37:59 PST
I'm going to skip the websockets test to make the tree green.  Ukai or Alexey or someone working on web-sockets can revisit the test at a later date.
Comment 25 Eric Seidel (no email) 2010-01-06 16:43:54 PST
Like Dave Levin, I have not been able to reproduce the failure locally.
Comment 26 Eric Seidel (no email) 2010-01-06 16:48:24 PST
Committed r52883: <http://trac.webkit.org/changeset/52883>
Comment 27 Eric Seidel (no email) 2010-01-06 16:50:51 PST
The story continues.  It seems that this test stopped consistently failing after:

It is still skipped and should probably remain skipped until someone with WebSockets experience can offer a guess as to what's going on here.
Comment 28 Eric Seidel (no email) 2010-01-06 16:51:36 PST
http://build.webkit.org/changes/5099 corresponds to http://trac.webkit.org/changeset/52877 in case buildbot's little mind forgets.
Comment 29 Eric Seidel (no email) 2010-01-06 17:08:39 PST
Alexey asked that I file a new bug.  I've done so.  bug 33279.

*** This bug has been marked as a duplicate of bug 33279 ***