http/tests/websocket/tests/hybi/stop-on-resume-in-error-handler.html crashes on Windows almost every time: https://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Ftests%2Fwebsocket%2Ftests%2Fhybi%2Fstop-on-resume-in-error-handler.html
Sadly the Windows bot doesn't give us a trace. I am going to skip the test for now and look into this when I find time.
Temporarily skipped in <http://trac.webkit.org/changeset/183191>.
<rdar://problem/20829027>
This seems to only happen in Release builds.
Created attachment 280086 [details] Patch
Comment on attachment 280086 [details] Patch Attachment 280086 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/1406444 Number of test failures exceeded the failure limit.
Created attachment 280087 [details] Archive of layout-test-results from ews103 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 280098 [details] Patch
Comment on attachment 280098 [details] Patch Thank you for fixing this! Can you unskip the test when you land the fix?
(In reply to comment #9) > Comment on attachment 280098 [details] > Patch > > Thank you for fixing this! Can you unskip the test when you land the fix? Will do :) Thanks for reviewing!
Committed r201500: <http://trac.webkit.org/changeset/201500>
Updated test expectations in <http://trac.webkit.org/changeset/201501>.
Comment on attachment 280098 [details] Patch Not sure how the protector helps since it is not capture by value in the lambda?
(In reply to comment #13) > Comment on attachment 280098 [details] > Patch > > Not sure how the protector helps since it is not capture by value in the > lambda? I added this to make sure the SocketStreamHandle object is not deleted before the call is executed on the main thread, and used a RefPtr since the thread will wait for the call to finish. Perhaps this is not needed?
Oh, I thought this was a callOnMainThread() call. I am not familiar with callOnMainThreadAndWait() but your change is probably fine then.
(In reply to comment #15) > Oh, I thought this was a callOnMainThread() call. I am not familiar with > callOnMainThreadAndWait() but your change is probably fine then. Sounds good, I actually think this file is the only place where callOnMainThreadAndWait() is used :)