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 .
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.
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
*** This bug has been marked as a duplicate of bug 59552 ***