Summary: | [WK2] WebProcess become unresponsive while running layout tests | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | abarth, ap, benjamin, eric.carlson, eric, ggaren, sam, simon.fraser, slewis, thorton, webkit-bug-importer |
Priority: | P1 | Keywords: | InRadar, LayoutTestFailure |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Ryosuke Niwa
2013-01-04 10:39:45 PST
Mountain Lion Debug bots randomly have the same issue. See <rdar://problem/12248711> for extensive backstory. 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? 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. It could be that WTR is in a bad state. Ideally we'd sample both processes. |