Bug 33256 – REGRESSION(52854?) fast/workers/shared-worker-constructor.html failed on Leopard Build Bot

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Tools / Tests

[Eric Seidel (no email)]

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:
http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52854%20(9006)/results.html
http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52854%20(9007)/results.html
http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52854%20(9008)/results.html
http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52854%20(9009)/results.html

Maybe the builds are failing to update on the test machine?

[Eric Seidel (no email)]

CCing Mark in case he knows of something going wrong with the bots.

[Eric Seidel (no email)]

Andrew added the test 4 months ago.

[David Levin]

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.

[Andrew Wilson]

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).

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

I wonder if the previous change http://trac.webkit.org/changeset/52853 could be related.  That at least changed run-webkit-tests...

[David Levin]

I'm currently unable to repro this locally (when running all tests using a retail build after sync'ing to the latest revision).

[Andras Becsi]

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 127.0.0.1:8000
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.

[Eric Seidel (no email)]

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.

[WebKit Review Bot]

style-queue ran check-webkit-style on attachment 45985 [details] without any errors.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

I'll land this by hand.

[Eric Seidel (no email)]

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>

[Eric Seidel (no email)]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

This does not seem to have fixed the problem:
http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52870%20(9022)/results.html

[Eric Seidel (no email)]

Looks like:
http/tests/appcache .(48)Address already in use: make_sock: could not bind to address 127.0.0.1:8000
no listening sockets available, shutting down
is still occuring in
http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Tests%29/builds/9022/steps/layout-test/logs/stdio
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.

[Eric Seidel (no email)]

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

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

Committed r52876: <http://trac.webkit.org/changeset/52876>

[Eric Seidel (no email)]

This does not seem to be my day.

The rollout did not fix the SL bot:
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r52876%20(3931)/results.html
The Leopard bot is still building.

The first revision we saw this was r52854
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/3919
but it is my suspicion that the revision was unrelated.

[Eric Seidel (no email)]

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:
http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52876%20(9024)/results.html

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.

[Eric Seidel (no email)]

Andrew Wilson is right.  The log must be coming  from the previous test as it would come from this line of code:
http://trac.webkit.org/browser/trunk/WebCore/websockets/WebSocketHandshake.cpp#L234

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

http://trac.webkit.org/browser/trunk/LayoutTests/fast/websockets/script-tests/websocket-event-target.js is the test in question.

[Eric Seidel (no email)]

Like Dave Levin, I have not been able to reproduce the failure locally.

[Eric Seidel (no email)]

Committed r52883: <http://trac.webkit.org/changeset/52883>

[Eric Seidel (no email)]

The story continues.  It seems that this test stopped consistently failing after:
http://build.webkit.org/changes/5099

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.

[Eric Seidel (no email)]

http://build.webkit.org/changes/5099 corresponds to http://trac.webkit.org/changeset/52877 in case buildbot's little mind forgets.

[Eric Seidel (no email)]

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 ***