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?
CCing Mark in case he knows of something going wrong with the bots.
Andrew added the test 4 months ago.
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.
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).
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.
I wonder if the previous change http://trac.webkit.org/changeset/52853 could be related. That at least changed run-webkit-tests...
I'm currently unable to repro this locally (when running all tests using a retail build after sync'ing to the latest revision).
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.
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.
style-queue ran check-webkit-style on attachment 45985 [details] without any errors.
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.
I'll land this by hand.
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>
All reviewed patches have been landed. Closing bug.
This does not seem to have fixed the problem: http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r52870%20(9022)/results.html
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.
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
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.
Committed r52876: <http://trac.webkit.org/changeset/52876>
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.
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.
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
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.
http://trac.webkit.org/browser/trunk/LayoutTests/fast/websockets/script-tests/websocket-event-target.js is the test in question.
Like Dave Levin, I have not been able to reproduce the failure locally.
Committed r52883: <http://trac.webkit.org/changeset/52883>
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.
http://build.webkit.org/changes/5099 corresponds to http://trac.webkit.org/changeset/52877 in case buildbot's little mind forgets.
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 ***