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

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Tim Horton <timothy_horton at apple.com>  2012-09-05 16:18:00 PST ---
(In reply to comment #1)
> I took a blind stab at fixing this by doubling the timeout length. https://bugs.webkit.org/show_bug.cgi?id=87720.  It didn't have any effect on the frequency, so I think this is more complicated than slow machines.
> 
> I can reproduce this locally by running with a lot of parallel processes, more than my machine is supposed to support.  Whether that is just reproducing the symptom instead of the root cause I don't know.

Ah, I'll have to try that.

> One theory I had was that this was related to plugin process crashes which aren't caught by the harness.

PluginProcess crashes shouldn't hang the WebProcess. We don't see that normally, do we?

> Another theory I have is that this is some kind of disk contention.  It could be that resetting the state is holding a lock on a file and that when multiple processes try to access it they time out.

Most of the timeouts are not during the reset settings to consistent state bit, they're mostly "during the test" i.e. after the page load started, but before didFinishLoad.

> Currently when WKTR notices the WebProcess didn't come back from this call it kills the WebProcess.  If we wanted to treat this as a timeout WKTR would need to modified to not kill the WebProcess.  If we did that restructuring we could get samples which might help diagnose the issue.

It ... has to kill the WebProcess, the WebProcess is *not responding*. (at least if by "not kill", you mean "use it for subsequent tests"). But yes, if we could sample it first that would be nice.

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