Bug 32381 – Assertion reached in FrameView::paintContents()

• Status: NEW
• Component: Layout and Rendering

[Daniel Jalkut]

I am debugging my app against trunk WebKit, compiled for arch i386, over the past few days.

A few times I have run into an assertion firing in FrameView::paintContents, at line 1685:

ASSERT(!needsLayout());

I don't know if my use of WebKit is unusual, or if this is an assertion that many people observe in day-to-day debugging. Just wanted to submit it in case I can help narrow down what is going on here to cause this assertion to fire irregularly in my usage.

#0  0x0136ebb2 in WebCore::FrameView::paintContents (this=0x60ada00, p=0xbfffd324, rect=@0xbfffd314) at /Volumes/Data/daniel/Sources/WebKit/WebCore/page/FrameView.cpp:1685
#1  0x0048b471 in -[WebFrame(WebInternal) _drawRect:contentsOnly:] (self=0x5ee6840, _cmd=0x96cc58d1, rect={origin = {x = 0, y = 0}, size = {width = 1026, height = 342}}, contentsOnly=1 '\001') at /Volumes/Data/daniel/Sources/WebKit/WebKit/mac/WebView/WebFrame.mm:530
#2  0x004bd7cb in -[WebHTMLView drawSingleRect:] (self=0x689f880, _cmd=0x96ccfdf0, rect={origin = {x = 0, y = 0}, size = {width = 1026, height = 342}}) at /Volumes/Data/daniel/Sources/WebKit/WebKit/mac/WebView/WebHTMLView.mm:3154
#3  0x004b5a51 in -[WebHTMLView drawRect:] (self=0x689f880, _cmd=0x90e8fcb8, rect={origin = {x = 0, y = 0}, size = {width = 1026, height = 342}}) at /Volumes/Data/daniel/Sources/WebKit/WebKit/mac/WebView/WebHTMLView.mm:3198
#4  0x907d2ce1 in -[NSView _drawRect:clip:] ()
#5  0x907d197f in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#6  0x004b3947 in -[WebHTMLView(WebPrivate) _recursiveDisplayAllDirtyWithLockFocus:visRect:] (self=0x689f880, _cmd=0x90e907d4, needsLockFocus=1 '\001', visRect={origin = {x = 0, y = 0}, size = {width = 1026, height = 342}}) at /Volumes/Data/daniel/Sources/WebKit/WebKit/mac/WebView/WebHTMLView.mm:1349
#7  0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#8  0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#9  0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#10 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#11 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#12 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#13 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#14 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#15 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#16 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#17 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#18 0x907d1cb4 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#19 0x907cfe9e in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#20 0x907cfa13 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#21 0x907cc359 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#22 0x9072cf26 in -[NSView displayIfNeeded] ()
#23 0x906f6292 in -[NSWindow displayIfNeeded] ()
#24 0x906f4d30 in -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] ()
#25 0x906f4892 in -[NSWindow orderWindow:relativeTo:] ()
#26 0x9086e962 in -[NSWindow orderFront:] ()
#27 0x906bd78a in -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] ()
#28 0x906bb64a in loadNib ()
#29 0x906bac9f in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] ()
#30 0x906ba955 in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] ()
#31 0x906ba8a0 in +[NSBundle(NSNibLoading) loadNibNamed:owner:] ()
#32 0x906b76a9 in NSApplicationMain ()
#33 0x000027b1 in main (argc=1, argv=0xbffff808) at main.m:63
Current language:  auto; currently c++

[Nikolas Zimmermann]

*** Bug 38206 has been marked as a duplicate of this bug. ***

[Nikolas Zimmermann]

*** Bug 34389 has been marked as a duplicate of this bug. ***

[Nikolas Zimmermann]

I'm seeing this assertion frequently in a rather complex SVG testcase, needs a reduction first.

Simon, Dan, do you already know what's going on? Anything comes to your mind, what might be causing this? Possibly related to updateLayout() calls? Still have to investigate...

[Simon Fraser (smfr)]

There is a "viewWillDraw" mechanism on Mac, and similar on other platforms, that is supposed to ensure that style updates and layout are completed before painting occurs.

This assertion fires when this assumption is violated. It indicates that someone marked a node as needing style update or layout after the layout completed.

[zalan]

I also ran into the layoutneeded() assert in FrameView::paintContents(). It isn't that easy to repro, but with trunk codebase (and qt WebKit2 build with tiling enabled), I was able to catch it a few times on nytimes.com.

I traced it down and found out that FrameView::layout() can actually return with dirty tree (pending layout). It looks, that calling FrameView::layout() (or FrameView::updateLayoutAndStyleIfNeededRecursive()) does not guarantee a clean tree anymore, so a subsequent call to FrameView::paintContents() could assert with !layoutneeded(). 
In the backtrace, i had on nytimes.com, i can see that performPostLayoutTasks() (line #839) can return with pending layout and layout() simply returns with that state. Notice, that last assert on needslayout is at #827, before performing the post layout tasks.
here is what happenes on nytimes.com
1, layout() gets called
2, it calls performPostLayoutTasks()
3, performPostLayoutTasks() initiates nested layout call
4, nested layout() returns with clean tree, but with pending post layout tasks.
5, sendEvent() inside performPostLayoutTasks() schedules a layout.
6, performPostLayoutTasks() returns with pending layout.
7, #842 checks whether layout is needed after performPostLayoutTasks(), but since there are pending post layout tasks from the nested layout() (m_hasPendingPostLayoutTasks = true), it ignores the needsLayout() and returns with pending layout.
8, needsLayout() asserts in a subsequent paint call

I did a quick check to clean the tree with calling layout(), but that introduced other issues.

[Beth Dakin]

<rdar://problem/8600214>

[Beth Dakin]

This is almost certainly a regression from http://trac.webkit.org/changeset/66552

[Viatcheslav Ostapenko]

*** Bug 48529 has been marked as a duplicate of this bug. ***

[Xan Lopez]

*** Bug 48939 has been marked as a duplicate of this bug. ***