[Webkit-unassigned] [Bug 26917] New: Increase delays in worker-terminate layout test to avoid false negatives

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 1 22:24:40 PDT 2009


           Summary: Increase delays in worker-terminate layout test to avoid
                    false negatives
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Macintosh
        OS/Version: Mac OS X 10.5
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dimich at chromium.org
                CC: ap at webkit.org, levin at chromium.org

The worker-terminate tests starts workers that replay with a message to a
message (like echo), then posts a message to them, immediately calls
'worker.terminate()' and then waits for a while to check that after calling
'terminate()' there is nothing coming back from the worker (it was terminated).
To make sure the worker started at all, before 'terminate()' it may wait for
the first message to come back (and be captured in results).

Current timeout for create a worker -> postMessage('ping1') -> wait for 'pong'
from the worker -> call terminate() -> postMessage('ping2') - wait to see that
there is no 'pong2' is set to 500ms.

On debug builds (of multi-process Chromium) and virtual test machines the time
until first pong returns is roughly 500ms these days. So the test is flakey in
some test environments, giving a fals negative when the first 'pong' is absent
- and it doesn't even start to test that the 'pong2' does not come during some
time after since it exits.

It is better to avoid such delay-based tests in general. In this case, I can't
think of a way to detect the termination of the worker other then to verify it
doesn't return messages anymore...

Proposed patch moves start of the timeout after 'pong1' and increases the
timeout 2x to make test more reliable.

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the webkit-unassigned mailing list