[Webkit-unassigned] [Bug 135168] ASSERT in Document::unregisterCollection reloading apple.com

[bugzilla-daemon at webkit.org]

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





--- Comment #2 from Zan Dobersek <zandobersek at gmail.com>  2014-07-22 14:41:09 PST ---
The issue is not with the assertion itself, but with the HashSet being properly zeroed out in Document::invalidateNodeListAndCollectionCaches() after HashTable gained proper move constructor and assignment operator.

The problematic HTMLCollection is of the DocLinks type. After it is created, the first change in any class attribute on www.apple.com (like hovering on/off a menu) results in the following call chain:

#0  WebCore::HTMLCollection::invalidateCache (this=0x3936000, attrName=0x7ffe59fb0de8 <WebCore::HTMLNames::classAttr>) at ../../Source/WebCore/html/HTMLCollection.h:114
#1  0x00007ffe56d016b9 in WebCore::Document::invalidateNodeListAndCollectionCaches (this=0x2b80a40, attrName=0x7ffe59fb0de8 <WebCore::HTMLNames::classAttr>)
    at ../../Source/WebCore/dom/Node.cpp:722
#2  0x00007ffe56d017e5 in WebCore::Node::invalidateNodeListAndCollectionCachesInAncestors (this=0x2788210, attrName=0x7ffe59fb0de8 <WebCore::HTMLNames::classAttr>, 
    attributeOwnerElement=0x2788210) at ../../Source/WebCore/dom/Node.cpp:742
#3  0x00007ffe56caeb78 in WebCore::Element::attributeChanged (this=0x2788210, name=..., oldValue=..., newValue=...) at ../../Source/WebCore/dom/Element.cpp:1103
#4  0x00007ffe56d52218 in WebCore::StyledElement::attributeChanged (this=0x2788210, name=..., oldValue=..., newValue=..., reason=WebCore::Element::ModifiedDirectly)
    at ../../Source/WebCore/dom/StyledElement.cpp:162
#5  0x00007ffe56cb2826 in WebCore::Element::didAddAttribute (this=0x2788210, name=..., value=...) at ../../Source/WebCore/dom/Element.cpp:2771
#6  0x00007ffe56cb27bb in WebCore::Element::addAttributeInternal (this=0x2788210, name=..., value=..., 
    inSynchronizationOfLazyAttribute=WebCore::Element::NotInSynchronizationOfLazyAttribute) at ../../Source/WebCore/dom/Element.cpp:1842
#7  0x00007ffe56cb83fb in WebCore::Element::setAttributeInternal (this=0x2788210, index=4294967295, name=..., newValue=..., 
    inSynchronizationOfLazyAttribute=WebCore::Element::NotInSynchronizationOfLazyAttribute) at ../../Source/WebCore/dom/Element.cpp:1032
#8  0x00007ffe56cae80a in WebCore::Element::setAttributeWithoutSynchronization (this=0x2788210, name=..., value=...) at ../../Source/WebCore/dom/Element.cpp:1014
#9  0x00007ffe57e489ff in WebCore::setJSElementClassName (exec=0x7fff008e45a0, baseObject=0x7ffe000bfdd0, thisValue=140728898809168, encodedValue=140728901566416)
    at DerivedSources/WebCore/JSElement.cpp:2276
#10 0x00007ffe5ac3e7c2 in JSC::callCustomSetter (exec=0x7fff008e45a0, customGetterSetter=..., base=0x7ffe000bfdd0, thisValue=..., value=...)
    at ../../Source/JavaScriptCore/runtime/CustomGetterSetter.cpp:44
#11 0x00007ffe5acb475e in JSC::JSObject::put (cell=0x7ffe0005ed50, exec=0x7fff008e45a0, propertyName=..., value=..., slot=...) at ../../Source/JavaScriptCore/runtime/JSObject.cpp:393
#12 0x00007ffe5a99c312 in JSC::JSValue::put (this=0x7fff008e4488, exec=0x7fff008e45a0, propertyName=..., value=..., slot=...) at ../../Source/JavaScriptCore/runtime/JSCJSValueInlines.h:729
#13 0x00007ffe5adbce45 in llint_slow_path_put_by_id (exec=0x7fff008e45a0, pc=0x3515a40) at ../../Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:637
#14 0x00007ffe5adc88a9 in llint_entry () from /home/zan/dvt/webkit/hackhack/WebKitBuild/Debug/lib/libjavascriptcoregtk-3.0.so.0
#15 0x00007ffe5adcbf2b in llint_entry () from /home/zan/dvt/webkit/hackhack/WebKitBuild/Debug/lib/libjavascriptcoregtk-3.0.so.0
#16 0x00007ffe5adc5706 in callToJavaScript () from /home/zan/dvt/webkit/hackhack/WebKitBuild/Debug/lib/libjavascriptcoregtk-3.0.so.0

HTMLCollection::invalidateCache() then does nothing since the collection won't be invalidated for any change to a class attribute (like it would be in case of a changed href attribute).

The Document::invalidateNodeListAndCollectionCaches() has already zeroed out the m_collectionsInvalidatedAtDocument HashSet so the assertion in Document::unregisterCollection() fails when it gets called during the HTMLCollection's destruction.

This wasn't a problem before the HashTable changes since the entries were simply copied, and the assertion wouldn't be hit.

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