[Webkit-unassigned] [Bug 95906] New: WKTR often reports an unresponsive WebProcess on Mac bots

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=95906

           Summary: WKTR often reports an unresponsive WebProcess on Mac
                    bots
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: timothy_horton at apple.com
                CC: mitz at webkit.org, slewis at apple.com,
                    simon.fraser at apple.com, jberlin at webkit.org,
                    dpranke at chromium.org


Some output from after my logging improvement yesterday (http://trac.webkit.org/changeset/127547):

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r127647%20(647)/fast/js/dfg-int32array-crash-log.txt

> No crash log found for WebProcess:16532.
> Process failed to become responsive before timing out.
>
> stdout:
> Timed out waiting for final message from web process
>
> stderr:
> #PROCESS UNRESPONSIVE - WebProcess (pid 16532)
> #EOF

http://build.webkit.org/results/Apple%20Lion%20Release%20WK2%20(Tests)/r127645%20(2940)/svg/animations/mozilla/animateMotion-by-1-crash-log.txt

> No crash log found for WebProcess:33091.
> Process failed to become responsive before timing out.
>
> stdout:
> Failed to reset to consistent state before the first test
> stderr:
> #PROCESS UNRESPONSIVE - WebProcess (pid 33091)
> #EOF

There are dozens upon dozens of examples of this happening, on Lion and Mountain Lion, across many machines. It seems to come in bunches - 20 tests from different shards will fail nearly simultaneously, and the harness will then give up.

I've never reproduced this locally, but it is one of the most significant issues blocking us from greenness on the Mac WK2 test bots, and has been for some time now.

Questions I have:

Is this the same (effectively) as a timeout for a test that doesn't call waitUntilDone (i.e. is this what you get if you have a non-waitUntilDone test, but then it hangs for some reason (infinite loop in JS, WebCore bug, whatever)?)?

If so, why don't we treat it as a timeout instead of a crash? (not that that would really help)

Could this be caused simply by slow/overloaded machines? (this is something I want to test locally)

Why does it come in batches, across many processes? (see http://build.webkit.org/results/Apple%20Lion%20Release%20WK2%20(Tests)/r127645%20(2940)/results.html)

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