[Webkit-unassigned] [Bug 33230] svg/W3C-SVG-1.1/animate-elem-30-t.svg crashing occasionally on Leopard Build Bot

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33230





--- Comment #17 from Darin Adler <darin at apple.com>  2010-01-07 12:50:22 PST ---
(In reply to comment #16)
> Is the problem that we're inside a layout already?
> 0   com.apple.WebCore                 0x05a578b3
> WebCore::SelectionController::recomputeCaretRect() + 145
> (SelectionController.cpp:929)
> 1   com.apple.WebCore                 0x0540c31b
> WebCore::Frame::selectionLayoutChanged() + 89 (Frame.cpp:642)
> 2   com.apple.WebCore                 0x054317eb
> WebCore::FrameView::layout(bool) + 2505 (FrameView.cpp:695)
> 3   com.apple.WebCore                 0x05431b41
> WebCore::FrameView::forceLayout(bool) + 31 (FrameView.cpp:1809)
> 4   com.apple.WebKit                  0x00af4879 -[WebHTMLView
> layoutToMinimumPageWidth:maximumPageWidth:adjustingViewSize:] + 259
> (WebHTMLView.mm:3012)
> 5   com.apple.WebKit                  0x00ae5128 -[WebHTMLView layout] + 68
> (WebHTMLView.mm:3026)

At that point in the layout process, needsLayout should already be false. I'm
guessing that there's some situation where SVG code creates the need for a new
layout while performing the current layout. That's a bug in SVG. But it may be
hard to track down.

This does reflect a real bug. Inside recomputeCaretRect it's going to create a
VisiblePosition and this will trigger a new layout! Extremely unpleasant.

I am not certain what the best thing to do is. We could remove the assertion
for now to un-flakify the bots, which is sad for all the non-SVG cases and
tests we could otherwise catch. We could add more targeted assertions to catch
code trigger new layout during the layout process to try to pinpoint where the
SVG code goes wrong.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.