Bug 59552 - ASSERTION FAILED: fontCache()->generation() == m_generation (running new-run-webkit-tests)
Summary: ASSERTION FAILED: fontCache()->generation() == m_generation (running new-run-...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac All
: P2 Normal
Assignee: mitz
URL:
Keywords:
: 60344 67031 71083 71139 72052 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-26 15:58 PDT by Geoffrey Garen
Modified: 2012-02-05 14:06 PST (History)
12 users (show)

See Also:


Attachments
Patch (1.40 KB, patch)
2011-11-14 03:14 PST, Tony Gentilcore
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Geoffrey Garen 2011-04-26 15:58:45 PDT
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&)
Comment 1 Geoffrey Garen 2011-04-26 15:59:36 PDT
BTW, I did this on my Mac Pro. On a less powerful computer, you may need to scale down --child-processes.
Comment 2 mitz 2011-04-26 16:07:42 PDT
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.
Comment 3 Yuta Kitamura 2011-11-07 02:07:40 PST
*** Bug 60344 has been marked as a duplicate of this bug. ***
Comment 4 Yuta Kitamura 2011-11-07 02:08:19 PST
*** Bug 67031 has been marked as a duplicate of this bug. ***
Comment 5 Yuta Kitamura 2011-11-07 02:08:40 PST
*** Bug 71139 has been marked as a duplicate of this bug. ***
Comment 6 Yuta Kitamura 2011-11-07 02:08:59 PST
*** Bug 71083 has been marked as a duplicate of this bug. ***
Comment 7 Yuta Kitamura 2011-11-07 02:21:07 PST
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.
Comment 8 Tony Chang 2011-11-07 15:57:35 PST
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
Comment 9 Tony Gentilcore 2011-11-14 03:14:21 PST
Created attachment 114909 [details]
Patch
Comment 10 Tony Gentilcore 2011-11-14 03:15:19 PST
Committed r100120: <http://trac.webkit.org/changeset/100120>
Comment 12 Peter Kasting 2011-11-15 15:19:42 PST
*** Bug 72052 has been marked as a duplicate of this bug. ***
Comment 13 Peter Kasting 2011-11-15 15:20:35 PST
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 ).
Comment 14 Steve Block 2011-11-17 07:00:39 PST
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.
Comment 15 Steve Block 2011-11-17 07:06:17 PST
Committed r100620: <http://trac.webkit.org/changeset/100620>
Comment 16 Steve Block 2011-11-17 09:39:20 PST
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.
Comment 17 Steve Block 2011-11-17 09:40:50 PST
Committed r100639: <http://trac.webkit.org/changeset/100639>
Comment 18 Steve Block 2011-11-18 09:28:52 PST
Also seen in fast/frames/sandboxed-iframe-parsing-space-characters.html - http://build.chromium.org/p/chromium.webkit/waterfall?builder=Webkit+Mac10.6+(dbg)
Comment 19 Steve Block 2011-11-18 09:35:01 PST
Committed r100784: <http://trac.webkit.org/changeset/100784>
Comment 20 Adam Klein 2011-11-18 10:24:11 PST
Committed r100788: <http://trac.webkit.org/changeset/100788>
Comment 21 Adam Klein 2011-11-18 10:24:58 PST
Accidentally closed by webkit-patch
Comment 23 Steve Block 2011-11-21 04:04:57 PST
Committed r100897: <http://trac.webkit.org/changeset/100897>
Comment 24 Adam Barth 2012-02-05 14:06:18 PST
Seems to be fixed?