|Summary:||fontconfig cache is invalidated too easily on mtime check|
|Product:||fontconfig||Reporter:||Chris Ball <chris-fdbugs>|
|Component:||fc-cache||Assignee:||Keith Packard <keithp>|
|Status:||RESOLVED DUPLICATE||QA Contact:|
|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!