This seems like a real bug, and not an artifact of new-run-webkit-tests, even though new-run-webkit-tests is essential to reproducing it reliably. * STEPS TO REPRODUCE: new-run-webkit-tests --child-processes=32 --experimental-fully-parallel ietestcenter inspector java ASSERTION FAILED: fontCache()->generation() == m_generation /Volumes/Big/ggaren/webkit/Source/WebCore/platform/graphics/FontFallbackList.cpp(104) : const WebCore::FontData* WebCore::FontFallbackList::fontDataAt(const WebCore::Font*, unsigned int) const 1 WebCore::FontFallbackList::fontDataAt(WebCore::Font const*, unsigned int) const 2 WebCore::FontFallbackList::primaryFontData(WebCore::Font const*) const 3 WebCore::FontFallbackList::primarySimpleFontData(WebCore::Font const*) 4 WebCore::Font::primaryFont() const 5 WebCore::Font::fontMetrics() const 6 WebCore::RenderInline::culledInlineBoundingBox(WebCore::RenderInline const*) const 7 WebCore::RenderInline::culledInlineBoundingBox(WebCore::RenderInline const*) const 8 WebCore::RenderInline::culledInlineVisualOverflowBoundingBox() const 9 WebCore::RenderInline::linesVisualOverflowBoundingBox() const 10 WebCore::RenderInline::clippedOverflowRectForRepaint(WebCore::RenderBoxModelObject*) 11 WebCore::RenderText::clippedOverflowRectForRepaint(WebCore::RenderBoxModelObject*) 12 WebCore::RenderObject::repaint(bool) 13 WebCore::RenderObjectChildList::removeChildNode(WebCore::RenderObject*, WebCore::RenderObject*, bool) 14 WebCore::RenderObject::removeChild(WebCore::RenderObject*) 15 WebCore::RenderObject::remove() 16 WebCore::RenderObject::destroy() 17 WebCore::RenderText::destroy() 18 WebCore::Node::detach() 19 WebCore::ContainerNode::detach() 20 WebCore::Element::detach() 21 WebCore::ContainerNode::detach() 22 WebCore::Element::detach() 23 WebCore::ContainerNode::removeChildren() 24 WebCore::replaceChildrenWithFragment(WebCore::HTMLElement*, WTF::PassRefPtr<WebCore::DocumentFragment>, int&) 25 WebCore::HTMLElement::setInnerHTML(WTF::String const&, int&) 26 WebCore::setJSHTMLElementInnerHTML(JSC::ExecState*, JSC::JSObject*, JSC::JSValue) 27 bool JSC::lookupPut<WebCore::JSHTMLElement>(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::HashTable const*, WebCore::JSHTMLElement*) 28 void JSC::lookupPut<WebCore::JSHTMLElement, WebCore::JSElement>(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::HashTable const*, WebCore::JSHTMLElement*, JSC::PutPropertySlot&) 29 WebCore::JSHTMLElement::put(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::PutPropertySlot&) 30 void JSC::lookupPut<WebCore::JSHTMLLIElement, WebCore::JSHTMLElement>(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::HashTable const*, WebCore::JSHTMLLIElement*, JSC::PutPropertySlot&) 31 WebCore::JSHTMLLIElement::put(JSC::ExecState*, JSC::Identifier const&, JSC::JSValue, JSC::PutPropertySlot&)
BTW, I did this on my Mac Pro. On a less powerful computer, you may need to scale down --child-processes.
Hyatt, is it new that we access font data as part of destroying a renderer? Sometimes we have stale font data in the render tree and we are counting on the ability to purge it by doing a forced style recalc, and not touching it before or during the style recalc.
*** Bug 60344 has been marked as a duplicate of this bug. ***
*** Bug 67031 has been marked as a duplicate of this bug. ***
*** Bug 71139 has been marked as a duplicate of this bug. ***
*** Bug 71083 has been marked as a duplicate of this bug. ***
Apparently this assertion failure happens intermittently on Chromium Mac bots. Here's a dashboard link showing frequency of this assertion failure: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fcss%2Fcounters%2Fcomplex-before.html%2Cstorage%2Fdomstorage%2Fevents%2Fbasic-body-attribute.html%2Cfast%2Fdom%2FElement%2Fid-in-frame.html%2Chttp%2Ftests%2Fsecurity%2Fcross-frame-access-custom.html%2Cfast%2Fframes%2Fcontent-opacity-2.html%2Cfast%2Fparser%2Fclose-while-stopping.html%2Cfast%2Fframes%2Fsandboxed-iframe-navigation-targetlink.html%2Cfast%2Fframes%2Fiframe-double-scale-contents.html (orange bit is a crash) Some findings: - This failure happens only on SnowLeopard. Leopard seems fine. - This failure does not have something to do with CoreGraphics/Skia separation.
Also seen in fast/frames/sandboxed-iframe-noscript.html and fast/frames/sandboxed-iframe-navigation-targetlink.html . http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fframes%2Fsandboxed-iframe-noscript.html%2Cfast%2Fframes%2Fsandboxed-iframe-navigation-targetlink.html&showExpectations=true
Created attachment 114909 [details] Patch
Committed r100120: <http://trac.webkit.org/changeset/100120>
Expected cross-frame-access-custom.html to crash. Example log: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=http%2Ftests%2Fsecurity%2Fcross-frame-access-custom.html
*** Bug 72052 has been marked as a duplicate of this bug. ***
Also now occurring in fast/dom/image-object.html (see e.g. http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28dbg%29/builds/6281/steps/webkit_tests/logs/stdio ).
Also seen in fast/frames/frame-unload-crash.html - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20(dbg)/builds/6313/steps/webkit_tests/logs/stdio. Will add CRASH expectation.
Committed r100620: <http://trac.webkit.org/changeset/100620>
Also seen in fast/dom/null-document-location-put-crash.html - http://build.chromium.org/p/chromium.webkit/waterfall?builder=Webkit+Mac10.6+(dbg) Will add CRASH expectation.
Committed r100639: <http://trac.webkit.org/changeset/100639>
Also seen in fast/frames/sandboxed-iframe-parsing-space-characters.html - http://build.chromium.org/p/chromium.webkit/waterfall?builder=Webkit+Mac10.6+(dbg)
Committed r100784: <http://trac.webkit.org/changeset/100784>
Committed r100788: <http://trac.webkit.org/changeset/100788>
Accidentally closed by webkit-patch
Also seen in jquery/offset.html - http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20%28CG%29%28dbg%29/builds/1692
Committed r100897: <http://trac.webkit.org/changeset/100897>
Seems to be fixed?