Bug 14494

Summary: answers.com crashes in paint with pending layout
Product: WebKit Reporter: Antti Koivisto <koivisto>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal Keywords: InRadar, Regression
Priority: P1    
Version: 523.x (Safari 3)   
Hardware: Mac   
OS: OS X 10.4   
URL: http://answers.com
Attachments:
Description Flags
crashing test aase none

Antti Koivisto
Reported 2007-07-02 00:24:08 PDT
Reduction: <body> <input id="s"> <script>document.getElementById("s").focus()</script> <link rel="stylesheet" href="x.css"/>
Attachments
crashing test aase (139 bytes, text/html)
2007-07-02 00:26 PDT, Antti Koivisto 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Antti Koivisto
Comment 1 2007-07-02 00:25:43 PDT
<rdar://problem/5297006>
Antti Koivisto
Comment 2 2007-07-02 00:26:59 PDT
Created attachment 15345 [details] crashing test aase stylesheet does not need to exist for the reduction to crash
Antti Koivisto
Comment 3 2007-07-02 00:31:57 PDT
The test case asserts in debug build but does not crash in release build. The original page crashes in release build too. This stack shows how layout gets invalidated from within FrameView::layout(). The method returns with layout still pending and subsequent synchronous paint crashes (or asserts): #0 0x010c4660 in WebCore::FrameView::scheduleRelayout at FrameView.cpp:658 #1 0x0116f125 in WebCore::RenderObject::scheduleRelayout at RenderObject.cpp:2725 #2 0x0116f2ed in WebCore::RenderObject::markContainingBlocksForLayout at RenderObject.cpp:737 #3 0x0116f3bb in WebCore::RenderObject::setNeedsLayout at RenderObject.cpp:689 #4 0x014e9589 in WebCore::RenderObject::setNeedsLayoutAndPrefWidthsRecalc at RenderObject.h:380 #5 0x010d4e3c in WebCore::Document::updateStyleSelector at Document.cpp:1946 #6 0x010d536d in WebCore::Document::updateLayoutIgnorePendingStylesheets at Document.cpp:1082 #7 0x011ef53c in WebCore::VisiblePosition::canonicalPosition at VisiblePosition.cpp:141 #8 0x011ef93e in WebCore::VisiblePosition::init at VisiblePosition.cpp:58 #9 0x011efb3a in WebCore::VisiblePosition::VisiblePosition at VisiblePosition.cpp:45 #10 0x011df628 in WebCore::SelectionController::layout at SelectionController.cpp:892 #11 0x011df823 in WebCore::SelectionController::caretRect at SelectionController.cpp:909 #12 0x011dfb34 in WebCore::SelectionController::recomputeCaretRect at SelectionController.cpp:949 #13 0x010b8b37 in WebCore::Frame::selectionLayoutChanged at Frame.cpp:584 #14 0x010b8d02 in WebCore::Frame::invalidateSelection at Frame.cpp:522 #15 0x010c69ef in WebCore::FrameView::layout at FrameView.cpp:433 #16 0x010ba2d9 in WebCore::Frame::forceLayout at Frame.cpp:1329 #17 0x010dbb70 in -[WebCoreFrameBridge forceLayoutAdjustingViewSize:] at WebCoreFrameBridge.mm:383 #18 0x0033b686 in -[WebHTMLView layoutToMinimumPageWidth:maximumPageWidth:adjustingViewSize:] at WebHTMLView.mm:2494 #19 0x0033b909 in -[WebHTMLView layout] at WebHTMLView.mm:2521 #20 0x0033727e in -[WebHTMLView(WebPrivate) _layoutIfNeeded] at WebHTMLView.mm:1352 #21 0x00337548 in -[WebHTMLView(WebPrivate) _web_layoutIfNeededRecursive:testDirtyRect:] at WebHTMLView.mm:1371 #22 0x00335c91 in -[WebHTMLView(WebPrivate) _recursiveDisplayAllDirtyWithLockFocus:visRect:] at WebHTMLView.mm:885
Antti Koivisto
Comment 4 2007-07-02 00:50:15 PDT
actually this seems to have been a duplicate of http://bugs.webkit.org/show_bug.cgi?id=14118 which was just fixed in r23866
Note You need to log in before you can comment on or make changes to this bug.