Bug 10900

Summary: fontconfig cache is invalidated too easily on mtime check
Product: fontconfig Reporter: Chris Ball <chris-fdbugs>
Component: fc-cacheAssignee: Keith Packard <keithp>
Status: RESOLVED DUPLICATE QA Contact:
Severity: normal    
Priority: medium CC: jg
Version: 2.4   
Hardware: x86 (IA32)   
OS: All   
Whiteboard:
i915 platform: i915 features:

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.