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.
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.
<rdar://problem/9125141>
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 =/
(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.
Google Chrome Mac dev channel (Release build)
Created attachment 96613 [details] Patch
https://trac.webkit.org/changeset/88475
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.
(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.