[Fontconfig] Re: Finding font filename

[Mike FABIAN]

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

> On Fri, 23 Dec 2005, Mike FABIAN wrote:
>
>> Was that an intentional change or is this a bug?
>
> That would be a bug.  I'll try to take a look at it, but it might take
> a while.
>
> There aren't duplicate fonts by any chance?

No, it seems to happen with any font I try. I certainly have
only one copy of CODE2000.TTF for example:

mfabian at magellan:~$ fc-match -v 'code2000'-16  | grep file
	file: "CODE2000.TTF"(s)
mfabian at magellan:~$ fc-list code2000 file 
/usr/X11R6/lib/X11/fonts/truetype/CODE2000.TTF: 
mfabian at magellan:~$

By the way, what is the reason for the "__DUMMY__" in

    /* Please do not revoke any of these bindings. */
    static const FcObjectType _FcBaseObjectTypes[] = {
        { "__DUMMY__",      FcTypeVoid, },
        { FC_FAMILY,	FcTypeString, },
        ...

in fcname.c?

I'm trying to find the reason for a crash in fontconfig triggered
by rxvt-unicode. I couldn't yet understand it but I have the suspicion
that it is related to the introduction of "__DUMMY__". I found
that this "__DUMMY__" is inserted into the pattern by fontconfig
when the pattern is expanded:

(gdb) p FcNameUnparse(new)
$11 = (
    FcChar8 *) 0x69a080 "Courier:maxglyphmemory=1048576:\\_\\_DUMMY\\_\\_=1048576:style=Regular:slant=0:weight=80:width=100:pixelsize=13:spacing=100:foundry=ibm:antialias=True:hintstyle=3:hinting=True:verticallayout=False:autohint=False:globaladvance=True:index=0:outline=True:scalable=True:dpi=112.059:rgba=5:scale=1:minspace=True:charset=  |>^1!|>^1!P0oWQ |>]![|>^1!|>^1!!!!%#|75TI|>[LD|>V<gOq6Yc!!K?&  !%J<G!!!)$      9;*f! !!!.%    !C3c.!(CUL!!!#& !!#0GML3F5B^T5s!!!!5tUGTV    !!#3H !!!!nMW<gJ !%A5F!%J<G  !!#6Ih~y(E(1+k7!!!%#!!!!Z    !!#AL(P9Wa(2oHj|>T)!!!#0F !!!!#  !!#DM  !!!!(!!!LG    !!+fv       !!!%(!!+u{!!!!F       :lang=aa|ast|ay|bi|br|ca|ch|cs|da|et|eu|fj|fo|fur|fy|gd|gl|gv|ho|hu|ia|id|ie|io|is|kl|lb|mg|mt|nb|nds|nn|no|oc|om|pl|rm|sk|sma|smj|so|sq|sv|sw|tn|tr|ts|vo|wa|wen|wo|xh|yap|zu:fontversion=0:fontformat=Type 1:embolden=False:embeddedbitmap=False"
(gdb) 

This looks a bit weird already and I found that I could easily
trigger a crash like by inserting __DUMMY__ into the pattern from
the start:

mfabian at magellan:~$ fc-match "foo:\\_\\_DUMMY\\_\\_=1"
Segmentation fault (core dumped)
mfabian at magellan:~$

I tentatively "fixed" this crash triggered by "fc-match" with
the following patch:

diff -ru fontconfig-2.3.93.20051222.orig/src/fcname.c fontconfig-2.3.93.20051222/src/fcname.c
--- fontconfig-2.3.93.20051222.orig/src/fcname.c	2005-12-21 16:47:42.000000000 +0100
+++ fontconfig-2.3.93.20051222/src/fcname.c	2005-12-23 17:55:04.000000000 +0100
@@ -703,7 +703,7 @@
 		for (;;)
 		{
 		    name = FcNameFindNext (name, ":,", save, &delim);
-		    if (t)
+		    if (t && strcmp(t->object, "__DUMMY__"))
 		    {
 			v = FcNameConvert (t->type, save, &m);
 			if (!FcPatternAdd (pat, t->object, v, FcTrue))

but this didn't help for rxvt-unicode.

When debugging rxvt-unicode, I found that shortly before crash the function

    const char *
    FcObjectPtrU (FcObjectPtr si)
    {
        const FcObjectTypeList  *l;
        int i, j;

        if (si > 0)
        {
            if (si < biggest_known_ntypes)
                return biggest_known_types[si].object;

            j = 0;
            for (l = _FcObjectTypes; l; l = l->next)
                for (i = 0; i < l->ntypes; i++, j++)
                    if (j == si)
                        return l->types[i].object;
        }

        return _FcUserObjectNames[-si].object;
    }

is called with si=45, then nothing can be found in
the for loops within "if (si > 0)" and finally 

        return _FcUserObjectNames[-si].object;

is reached. An array index of -45 looks weird and it is not surprising
that junk is returned and fontconfig crashes soon later.

Maybe si=45 is already bigger than it should ever get?

Could this be related to introducing the extra object __DUMMY__?

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