[Trac #1525] fontconfig cache is invalidated too easily on mtime check

[Zarro Boogs per Child]

#1525: fontconfig cache is invalidated too easily on mtime check
---------------------+------------------------------------------------------
  Reporter:  jg      |       Owner:  cjb     
      Type:  defect  |      Status:  new     
  Priority:  high    |   Milestone:  Trial-2 
 Component:  distro  |     Version:          
Resolution:          |    Keywords:  upstream
  Verified:  0       |  
---------------------+------------------------------------------------------
Old description:

> https://bugs.freedesktop.org/show_bug.cgi?id=10900 is the upstream bug.
>
> 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.

New description:

 https://bugs.freedesktop.org/show_bug.cgi?id=10900 is the upstream bug.

 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.


 Workarounds:  Set the date to the current date; run fc-cache -r from the
 console.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1525#comment:1>
One Laptop Per Child <http://laptop.org/>