[chromium] ASSERTION FAILED: fontCache()->generation() == m_generation

• Component: WebKit Misc.
• Status: RESOLVED DUPLICATE

[Tony Gentilcore]

Jamesr noticed an ASSERT() fail on the mac bot:
ASSERTION FAILED: fontCache()->generation() == m_generation
 
build log:
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20(CG)(dbg)/builds/202/steps/webkit_tests/logs/stdio

test was:
fast/css-generated-content/table-before-after-child-add.html

This ASSERT was added by mitz back in http://trac.webkit.org/changeset/35025 , so it is likely a problem w/ the chromium mac port rather than with the ASSERT itself. If this ASSERT is reached, it means that FontCache::invalidate() was called. One place we call that is in WebKit/chromium/src/WebFontCache.cpp::clear(). That gets called on low memory notification (from ChromeRenderProcessObserver::OnPurgeMemory()), and from the ASSERT it seems like that isn't safe to do. That was added way back in http://codereview.chromium.org/267021 .

[Peter Kasting]

At the time I wrote that code, the purge memory call could never happen except manually (it explicitly did not happen in response to memory pressure notifications from the OS).  Perhaps since then someone has hooked this up to another signal.

I don't have a clue about the semantics of this stuff.  It sounds as if invalidate() is never safe to call, which sounds strange.  Feel free to fix however is correct.

[Julien Chaffraix]

FYI, the snow-leopard bots are randomly hitting this ASSERT as part of storage/domstorage/events/basic-body-attribute.html. Look for the test name in http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.6%20(dbg)/builds/5874/steps/webkit_tests/logs/stdio

[Yuta Kitamura]

*** This bug has been marked as a duplicate of bug 59552 ***