Bug 70619 – REGRESSION (r97496-r97499): 6 fast/workers tests failing on SnowLeopard Intel Release (Tests)

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Simon Fraser (smfr)]

The following tests started failing on SnowLeopard Intel Release (Tests) between r97497 and r97499 (inclusive):

    fast/workers/shared-worker-lifecycle.html
    fast/workers/shared-worker-frame-lifecycle.html
    fast/workers/storage/interrupt-database.html
    fast/workers/worker-close-more.html
    fast/workers/dedicated-worker-lifecycle.html
    fast/workers/worker-lifecycle.html

http://trac.webkit.org/log/trunk?rev=97499&stop_rev=97497&limit=4

http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r97496%20(33906)/results.html passed
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r97499%20(33907)/results.html failed

[Simon Fraser (smfr)]

Please can you try to make these workers tests less flakey? They cause so much bot redness.

[David Levin]

Adding dslomov as fyi.

I think Drew added most of these except for the interrupt-database one which I think Michael owns.

I think everyone is booked at the moment but hopefully one of us will be able to look at this soon.

[Simon Fraser (smfr)]

We need to get these workers tests skipped, or passing. Their flakiness is not acceptable.

[David Levin]

Feel free to skip them unless someone volunteers to fix them (which doesn't look like it is happening at present).

[Simon Fraser (smfr)]

Skipped in http://trac.webkit.org/changeset/99125

[Andrew Wilson]

Yeah, if you look at the failures, they look to be DRT failures more than anything else.

Looking at fast/workers/resources/worker-lifecycle.js:

if (window.layoutTestController) {
    layoutTestController.dumpAsText();
    layoutTestController.waitUntilDone();
    waitUntilWorkerThreadsExit(runTests);
} else {
    log("NOTE: Test relies on window.layoutTestController to detect when worker threads have exited. Please run this test via DumpRenderTree");
    waitUntilWorkerThreadsExit(runTests);
}

function runTests()
{
    if (window.layoutTestController)
        log("PASS: workerThreadCount = " + layoutTestController.workerThreadCount);

I don't see how it's possible for the test output to be missing "PASS: workerThreadCount =" unless layoutTestController.workerThreadCount() just blocks.

So, yeah, it'd be nice for someone to diagnose why DRT is not working with workers on the bots, but it doesn't specifically look like a failure in the worker code.

[David Levin]

I think all of these tests rely on waitUntilWorkerThreadsExit which to my memory is just plain flaky for jsc due to how garbage collection is done there.

I think Drew Wilson tried to fix this but it was usually a form of let's try this because it is hard to force the gc to happen and recognize that an object is not referred to anymore.

I bet they started failing due to all the gc changes that have been happening and I suspect that it isn't worth the trouble to keep them running on jsc. (I believe they work for v8 and this in turn will test the shared code in WebKit for this stuff which is the most important thing.)

[Andrew Wilson]

Still not 100% clear why we're not getting *any* output, but maybe if we get a timeout we don't dump the current text contents of the DOM (clearly my WebKit-fu is getting rusty).

[Simon Fraser (smfr)]

cc some JSC/GC folks.

[David Levin]

I bet this is the same as 71695.  If so, this is related to changing to NRWT.


After landing that fix, I'll unskip these and we'll see if they start passing, so I'll take this for now.

[David Levin]

Created attachment 118635 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 118635 [details]
Patch

This kind of change generally doesn't need review.

[WebKit Review Bot]

Comment on attachment 118635 [details]
Patch

Clearing flags on attachment: 118635

Committed r102510: <http://trac.webkit.org/changeset/102510>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.