Bug 106108 - [WK2] WebProcess become unresponsive while running layout tests
Summary: [WK2] WebProcess become unresponsive while running layout tests
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P1 Normal
Assignee: Nobody
Keywords: InRadar, LayoutTestFailure
Depends on:
Reported: 2013-01-04 10:39 PST by Ryosuke Niwa
Modified: 2013-03-20 10:00 PDT (History)
11 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ryosuke Niwa 2013-01-04 10:39:45 PST
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.

Timed out waiting for final message from web process

#PROCESS UNRESPONSIVE - WebProcess (pid 74888)

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)


It's happening on almost every build.
Comment 1 Radar WebKit Bug Importer 2013-01-04 10:40:54 PST
Comment 2 Benjamin Poulain 2013-01-17 19:44:39 PST
Mountain Lion Debug bots randomly have the same issue.
Comment 3 Tim Horton 2013-01-17 19:54:09 PST
See <rdar://problem/12248711> for extensive backstory.
Comment 4 Ryosuke Niwa 2013-03-20 00:57:22 PDT
Now that we have Simon's sampling feature checked in, we have a little more insight:



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?
Comment 5 Geoffrey Garen 2013-03-20 09:44:33 PDT
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.
Comment 6 Simon Fraser (smfr) 2013-03-20 10:00:01 PDT
It could be that WTR is in a bad state. Ideally we'd sample both processes.