Crash inside RenderObject::localToAbsolute below FrameView::layout

• Component: Layout and Rendering
• Status: RESOLVED FIXED

Created attachment 42439 [details]
Code sample that crashed webkit based browser (rigged to crash on clicking an anchor)

I am seeing a very very odd crasher that seemingly is related to layout... and apparently the phase of the moon on sunday.
I have attached as minimal a reproduction case as I could get. It seems to be a compounded bug that depends on a typo in a CSS rule and the right mix of DOM structure and CSS.

The code sample has comments that should further elaborate on the crasher.
Note that clicking the "die" anchor WILL CRASH THE BROWSER (or tab if you are using chrome).

It is failing this assert in RenderObject.cpp (line 214):
ASSERT(!node() || documentBeingDestroyed() || !document()->frame()->view() || document()->frame()->view()->layoutRoot() != this);


Stack trace of the crash:
 	chrome.dll!WebCore::RenderObject::~RenderObject()  Line 214 + 0x75 bytes	C++
 	chrome.dll!WebCore::RenderBoxModelObject::~RenderBoxModelObject()  Line 58 + 0x8 bytes	C++
 	chrome.dll!WebCore::RenderBox::~RenderBox()  Line 82 + 0x13 bytes	C++
 	chrome.dll!WebCore::RenderBlock::~RenderBlock()  Line 156 + 0x13 bytes	C++
 	chrome.dll!WebCore::RenderTextControl::~RenderTextControl()  Line 83 + 0x16 bytes	C++
 	chrome.dll!WebCore::RenderTextControlSingleLine::~RenderTextControlSingleLine()  Line 69 + 0x6a bytes	C++
 	chrome.dll!WebCore::RenderTextControlSingleLine::`scalar deleting destructor'()  + 0x16 bytes	C++
 	chrome.dll!WebCore::RenderObject::arenaDelete(WebCore::RenderArena * arena=0x045e8540, void * base=0x0700f30c)  Line 1923 + 0x22 bytes	C++
 	chrome.dll!WebCore::RenderObject::destroy()  Line 1897	C++
 	chrome.dll!WebCore::RenderBoxModelObject::destroy()  Line 76	C++
 	chrome.dll!WebCore::RenderBox::destroy()  Line 96	C++
 	chrome.dll!WebCore::RenderBlock::destroy()  Line 197	C++
 	chrome.dll!WebCore::Node::detach()  Line 1256 + 0x1d bytes	C++
 	chrome.dll!WebCore::ContainerNode::detach()  Line 591	C++
 	chrome.dll!WebCore::Element::detach()  Line 751	C++
>	chrome.dll!WebCore::HTMLInputElement::detach()  Line 880	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 803 + 0x12 bytes	C++
 	chrome.dll!WebCore::HTMLFormControlElement::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 240	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Element::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 867 + 0x16 bytes	C++
 	chrome.dll!WebCore::Document::recalcStyle(WebCore::Node::StyleChange change=NoChange)  Line 1285 + 0x16 bytes	C++
 	chrome.dll!WebCore::Document::updateStyleIfNeeded()  Line 1326 + 0x14 bytes	C++
 	chrome.dll!WebCore::Document::updateLayout()  Line 1352 + 0x12 bytes	C++
 	chrome.dll!WebCore::Document::updateLayoutIgnorePendingStylesheets()  Line 1390	C++
 	chrome.dll!WebCore::CSSComputedStyleDeclaration::getPropertyCSSValue(int propertyID=1051, WebCore::EUpdateLayout updateLayout=UpdateLayout)  Line 663	C++
 	chrome.dll!WebCore::CSSComputedStyleDeclaration::getPropertyCSSValue(int propertyID=1051)  Line 580 + 0x12 bytes	C++
 	chrome.dll!WebCore::CSSComputedStyleDeclaration::getPropertyValue(int propertyID=1051)  Line 1439 + 0x17 bytes	C++
 	chrome.dll!WebCore::CSSStyleDeclaration::getPropertyValue(const WebCore::String & propertyName={...})  Line 53 + 0x17 bytes	C++
 	chrome.dll!WebCore::CSSStyleDeclarationInternal::getPropertyValueCallback(const v8::Arguments & args={...})  Line 80 + 0x10 bytes	C++
 	chrome.dll!v8::internal::Builtin_HandleApiCall(v8::internal::Arguments args={...})  Line 383 + 0x13 bytes	C++
 	02e3018b()	
 	chrome.dll!v8::internal::Invoke(bool construct=false, v8::internal::Handle<v8::internal::JSFunction> func={...}, v8::internal::Handle<v8::internal::Object> receiver={...}, int argc=1, v8::internal::Object * * * args=0x0452e974, bool * has_pending_exception=0x0452e8a3)  Line 103 + 0x19 bytes	C++
 	chrome.dll!v8::internal::Execution::Call(v8::internal::Handle<v8::internal::JSFunction> func={...}, v8::internal::Handle<v8::internal::Object> receiver={...}, int argc=1, v8::internal::Object * * * args=0x0452e974, bool * pending_exception=0x0452e8a3)  Line 129 + 0x1f bytes	C++

[Mark Rowe (bdash)]

<rdar://problem/7363434>

I can’t reproduce the crash with attachment 42439 [details] on Mac OS X with TOT and on Windows with a slightly older build.

It still crashes for me at webkit r50535 which is pretty near ToT.

It is pulling in jQuery 1.3.2 over the network. You should try again to see if you had a network hiccup of some sort.

Confirmed to crash on the latest webkit nightly on Mac OSX.

@mitz: What revision were you trying at? (I am building ToT now to test)

After several attempts, I managed to reproduce the crash in TOT.

Very similar to <rdar://problem/7094146>, which was fixed in <http://trac.webkit.org/changeset/49484>.

I have a simplified version of the test case that sometimes triggers the crash. When it happens, I can see that very early on the render tree enters an inconsistent state, where a renderer is marked dirty even though its container is not (and it’s not the subtree layout root). This is caused by RenderLayer::setStaticY() telling setChildNeedsLayout() not to mark parents.

Related earlier changes are r19784 and r19148.

Created attachment 42710 [details]
Make setStaticY() not mark the object for layout

Fixed in <http://trac.webkit.org/projects/webkit/changeset/50623>.