Bug 106108 – [WK2] WebProcess become unresponsive while running layout tests

• Status: NEW
• Component: WebKit2

[Ryosuke Niwa]

I'm seeing multiple indefinite set of tests crashing with outputs like:

No crash log found for WebProcess:74888.
Process failed to become responsive before timing out.

stdout:
Timed out waiting for final message from web process

stderr:
#PROCESS UNRESPONSIVE - WebProcess (pid 74888)
#EOF

on Lion debug bots for the past couple of days (sorry, I should have filed earlier but there had been 7-8 other crashes and assertion failures so I'm going through them one by one)

e.g.
http://build.webkit.org/results/Apple%20Lion%20Release%20WK2%20(Tests)/r138805%20(6632)/results.html
http://build.webkit.org/results/Apple%20Lion%20Release%20WK2%20(Tests)/r138804%20(6631)/results.html
http://build.webkit.org/results/Apple%20Lion%20Release%20WK2%20(Tests)/r138802%20(6630)/results.html

It's happening on almost every build.

[Radar WebKit Bug Importer]

<rdar://problem/12958144>

[Benjamin Poulain]

Mountain Lion Debug bots randomly have the same issue.

[Tim Horton]

See <rdar://problem/12248711> for extensive backstory.

[Ryosuke Niwa]

Now that we have Simon's sampling feature checked in, we have a little more insight:

e.g.
http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r146305%20(7948)/results.html

http://build.webkit.org/results/Apple%20MountainLion%20Debug%20WK2%20(Tests)/r146305%20(7948)/fast/events/platform-wheelevent-in-scrolling-div-sample.txt

It seems like we're stuck in the middle of mark & sweep. I've seen similar sample data for unresponsive WebProcesses on multiple times.  Perhaps UIProcess is prematurely deciding WebProcess to be unresponsive during mark & sweep?

[Geoffrey Garen]

Actually, 99.8% of the samples are of the main thread sleeping:

    +                     983 ReceiveNextEventCommon  (in HIToolbox) + 356  [0x7fff987fec52]
    +                       983 RunCurrentEventLoopInMode  (in HIToolbox) + 209  [0x7fff987feeb4]
    +                         983 CFRunLoopRunSpecific  (in CoreFoundation) + 290  [0x7fff8de930e2]
    +                           981 __CFRunLoopRun  (in CoreFoundation) + 1078  [0x7fff8de93916]
    +                           ! 981 __CFRunLoopServiceMachPort  (in CoreFoundation) + 195  [0x7fff8de8e233]
    +                           !   981 mach_msg  (in libsystem_kernel.dylib) + 70  [0x7fff8bfb6c42]
    +                           !     981 mach_msg_trap  (in libsystem_kernel.dylib) + 10  [0x7fff8bfb7686]

There seems to be a bug in unresponsiveness detection.

[Simon Fraser (smfr)]

It could be that WTR is in a bad state. Ideally we'd sample both processes.