Bug 10900 - fontconfig cache is invalidated too easily on mtime check
Summary: fontconfig cache is invalidated too easily on mtime check
Status: RESOLVED DUPLICATE of bug 12107
Alias: None
Product: fontconfig
Classification: Unclassified
Component: fc-cache (show other bugs)
Version: 2.4
Hardware: x86 (IA32) All
: medium normal
Assignee: Keith Packard
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-09 18:45 UTC by Chris Ball
Modified: 2007-10-25 00:43 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Chris Ball 2007-05-09 18:45:43 UTC
At OLPC, we recently received some laptops with their clocks set to a date in 1999, and the root filesystem (which was built on a build server with an accurate RTC) set to a time in 2007.

The result of running this image was that web page rendering (or anything using fontconfig) resulted in the process that was doing the rendering jumping to 100% CPU for many minutes and failing to update at all, where normally it would have completed in a few seconds.  Using strace showed it to be reopening the same set of .ttf files many (~70) times each, and not using the valid cache in /var/cache/fontconfig.

Eventually, we noticed that the RTC on the laptop was incorrect, set the system time correctly, and immediately the page loaded in seconds.  Looking at the fontconfig cache code, it looks like the cache is treated as invalid if the mtime of the cache is greater than the system time.

There are several possible bugs here:

* Why do this check at all?  If you must, would it be possible to complain loudly when the cache is found to be invalid?

* If the cache is found to be invalid, why not clear up the problem by generating a new one (once) in the user's $HOME and using that, rather than giving up on any caching at all?

Hope that all makes sense.  I'd be happy to supply more information -- I can reproduce the problem by setting the machine's RTC back to 1999 again.

Thanks!
Comment 1 Keith Packard 2007-10-25 00:43:02 UTC

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


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.