Bug 61159 – Crashes in RenderLayerBacking::paintingGoesToWindow

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[James Robinson]

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.

[James Robinson]

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.

[Simon Fraser (smfr)]

<rdar://problem/9125141>

[William Chan]

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 =/

[James Robinson]

(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.

[William Chan]

Google Chrome Mac dev channel (Release build)

[Simon Fraser (smfr)]

Created attachment 96613 [details]
Patch

[Simon Fraser (smfr)]

https://trac.webkit.org/changeset/88475

[James Robinson]

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.

[Simon Fraser (smfr)]

(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.