Bug 61159

Summary: Crashes in RenderLayerBacking::paintingGoesToWindow
Product: WebKit Reporter: James Robinson <jamesr>
Component: New BugsAssignee: Simon Fraser (smfr) <simon.fraser>
Status: RESOLVED FIXED    
Severity: Normal CC: cmarrin, enne, simon.fraser, vangelis, willchan
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch darin: review+

Description James Robinson 2011-05-19 17:56:06 PDT
We're seeing a number of crashes in RenderLayerBacking::paintingGoesToWindow(), mostly on maps.google.com but also on some other pages.  The top of the callstack looks like:

Source/WebCore/rendering/RenderLayer.h:164]	WebCore::RenderLayerBacking::paintingGoesToWindow
Source/WebCore/rendering/RenderLayer.cpp:3907]	WebCore::RenderLayer::setBackingNeedsRepaintInRect
Source/WebCore/rendering/RenderObject.cpp:1168]	WebCore::RenderObject::repaintUsingContainer
Source/WebCore/rendering/RenderObject.cpp:1238]	WebCore::RenderObject::repaintAfterLayoutIfNeeded
Source/WebCore/rendering/RenderObject.h:812]	WebCore::RenderBlock::layoutBlock
Source/WebCore/rendering/RenderBlock.cpp:1135]	WebCore::RenderBlock::layout

(from http://code.google.com/p/chromium-os/issues/detail?id=15377).  We have had no success trying to reproduce locally and suspect it has something to do with the loading order or something else difficult to reproduce.

The crash is a null pointer deref on the repaintContainer's m_backing.  So it seems that when we enter RenderObject::repaintUsingContainer our RenderView has a non-null m_compositor and that the compositor's m_compositing flag is true, but the layer doesn't have a backing yet.  I suspect that we've entered compositing mode but somehow haven't yet update the layers, but am not sure.
Comment 1 James Robinson 2011-05-19 17:56:42 PDT
I'm planning to add a check for layer()->isCompositing() on this line: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderObject.cpp?rev=86705#L1187 in a chromium release branch to see if that has any impact on the crash rate.
Comment 2 Simon Fraser (smfr) 2011-05-20 08:10:46 PDT
<rdar://problem/9125141>
Comment 3 William Chan 2011-06-04 23:35:53 PDT
Hey James, I ran into this crash a few minutes ago. It was reproducible for me on Google Maps by looking up directions. I was able to crash it twice. After looking up this bug report, I stopped being able to reproduce it =/
Comment 4 James Robinson 2011-06-06 10:43:17 PDT
(In reply to comment #3)
> Hey James, I ran into this crash a few minutes ago. It was reproducible for me on Google Maps by looking up directions. I was able to crash it twice. After looking up this bug report, I stopped being able to reproduce it =/

Were you in debug or release?  It'd be useful to know if the ASSERT()s we have in place already are tripping or not.
Comment 5 William Chan 2011-06-08 06:07:12 PDT
Google Chrome Mac dev channel (Release build)
Comment 6 Simon Fraser (smfr) 2011-06-09 11:48:01 PDT
Created attachment 96613 [details]
Patch
Comment 7 Simon Fraser (smfr) 2011-06-09 13:07:46 PDT
https://trac.webkit.org/changeset/88475
Comment 8 James Robinson 2011-06-13 11:35:10 PDT
Early indications from our crash reports indicate that this may have fixed the crash.  Any idea on how we get to this function when isComposited() is false?  This only seems possible if repaintUsingContainer() is called when compositing is active with a repaintContainer that is not a RenderView.
Comment 9 Simon Fraser (smfr) 2011-06-13 11:39:35 PDT
(In reply to comment #8)
> Early indications from our crash reports indicate that this may have fixed the crash.  Any idea on how we get to this function when isComposited() is false?  This only seems possible if repaintUsingContainer() is called when compositing is active with a repaintContainer that is not a RenderView.

It's probably one of those cases where painting plugins runs script or something.