Patrick Lam <plam@xxxxxxx> ????????:
> 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@magellan:~$ fc-match -v 'code2000'-16 | grep file
file: "CODE2000.TTF"(s)
mfabian@magellan:~$ fc-list code2000 file
/usr/X11R6/lib/X11/fonts/truetype/CODE2000.TTF:
mfabian@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@magellan:~$ fc-match "foo:\\_\\_DUMMY\\_\\_=1"
Segmentation fault (core dumped)
mfabian@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@xxxxxxx> http://www.suse.de/~mfabian
?????????????
