[Fontconfig] incompatible changes in cache format (was: most fonts don't support English anymore???)

[Mike FABIAN]

Patrick Lam <plam at MIT.EDU> さんは書きました:

> Mike FABIAN wrote:
>> I found that this problem is a side effect of the attached
>> "euro.patch" which I apply to the SuSE fontconfig package to make sure
>> that default fonts for European languages (including English) always
>> have an Euro symbol.
>> 
>> But this patch is trivial and I think correct, therefore there
>> are some severe bugs in code related to lang.
>> 
>> Takashi Iwai <tiwai at suse.de> fixed the problem yesterday,
>> his patch (fc-lang-idx-fixes.diff) is attached.
>
> Ok, I changed the cache format so that it uses the same format as
> fc-lang generates.  Please test the latest CVS version.

Your change in the cache format causes crashes on systems where
old caches are still around, i.e. it causes crashes after updating.

GTK2 applications crash with a backtrace like this:

The backtrace of a crash looks like below:
#0  0xb7996fa7 in FcCharSetUnionLeaf (result=0xbf815494, al=0x5fd0742c,
    bl=0x810f1f0) at fccharset.c:509
#1  0xb7998ce1 in FcCharSetOperate (a=0xb744844c, b=0x810eb78,
    overlap=0xb7996f90 <FcCharSetUnionLeaf>, aonly=1, bonly=1)
    at fccharset.c:465
#2  0xb79a3623 in FcFontSetSort (config=0x80f9520, sets=0xbf8155dc, nsets=1,
    p=0x80f95a0, trim=1, csp=0x0, result=0xbf815754) at fcmatch.c:812
#3  0xb79a3984 in FcFontSort (config=0x810f1f0, p=0x80f95a0, trim=1, csp=0x0,
    result=0xbf815754) at fcmatch.c:1031
#4  0xb7b18198 in pango_fc_font_map_get_type ()
   from /opt/gnome/lib/libpangoft2-1.0.so.0
#5  0xb7aec820 in pango_font_map_load_fontset ()
   from /opt/gnome/lib/libpango-1.0.so.0
#6  0xb7aea83a in pango_context_get_font_description ()
   from /opt/gnome/lib/libpango-1.0.so.0
#7  0xb7aeab82 in pango_itemize_with_base_dir ()
   from /opt/gnome/lib/libpango-1.0.so.0
#8  0xb7af2afb in pango_layout_iter_get_char_extents ()
   from /opt/gnome/lib/libpango-1.0.so.0
#9  0xb7af36cc in pango_layout_iter_get_char_extents ()
   from /opt/gnome/lib/libpango-1.0.so.0
#10 0xb7d0f96d in gtk_label_new () from /opt/gnome/lib/libgtk-x11-2.0.so.0

similar crashes with similar backtraces happen with "fc-match -s
sans", i.e. everything calling FcFontSort () crashes.

The crashes can be "fixed" by calling "fc-cache -f -v" and removing
all old ~/.fonts.cache-q files in the home directories of users.

How to deal with such incompatible changes in cache files?

Frederic Crozat wrote recently that he calls "fc-cache -f" in the post
install script of his fontconfig RPM-package.  But even that won't be
enough if old ~/.fonts.cache-2 files are still there.

Either incompatible changes should never happen (probably not
realistic) or fontconfig should somehow detect old cache files which
are incompatible to the current version of fontconfig.

fcint.h contains a magic number

    #define FC_CACHE_MAGIC 0xFC02FC02

which appears to be intended for that purpose.

Maybe that number should be incremented with each incompatible change
to invalidate old, incompatible cache files?

I just tried that and it seems to work partly.

    fc-match sans

generates a complete ~/.fonts.cache-2 file for all fonts in my system
although the time stamps of the cache files in /var/cache/fontconfig
appear to be OK. But

    fc-cache -v

run as root doesn't generate new caches in /var/cache/fontconfig,
it just skips:

    mfabian at magellan:~$ sudo fc-cache -v
    fc-cache: "/usr/share/fonts": skipping, 0 fonts, 3 dirs
    [...]

It skips very slowly though, it takes as much time for skipping as for
generating new cache files, i.e. fontconfig seems to notice that there
is something wrong with these caches. Nevertheless fc-cache doesn't
write new files unless called with "-f". After that, "fc-cache -v"
skips fast again.

Do you agree that FC_CACHE_MAGIC should be incremented with each
incompatible change?

If yes, we probably should fix these issues.

-- 
Mike FABIAN   <mfabian at suse.de>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。