Bug 22538 - xfs (4.0.2) crashes when trying to access TrueType fonts
Summary: xfs (4.0.2) crashes when trying to access TrueType fonts
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 1.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
: 23575 26070 31471 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-19 17:29 UTC by Bernhard Rosenkraenzer
Modified: 2005-10-31 22:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-01 18:31:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Sample TrueType fonts (from OpenOffice) to reproduce this (530.07 KB, application/octet-stream)
2000-12-19 17:39 UTC, Bernhard Rosenkraenzer
no flags Details
XFree86-4.0.2-xfscrash.patch (561 bytes, patch)
2001-03-13 09:20 UTC, Tim Waugh
no flags Details | Diff

Description Bernhard Rosenkraenzer 2000-12-19 17:29:27 UTC
Subject says it all - 4.0.1-1.3 is ok. I guess the new Xrender stuff is
messing up.

This happens to me on a system with all packages from 7.1 installed, using
a Matrox G400 card, using the "freetype" module in XF86Config-4.

Comment 1 Bernhard Rosenkraenzer 2000-12-19 17:39:54 UTC
Created attachment 6576 [details]
Sample TrueType fonts (from OpenOffice) to reproduce this

Comment 2 Bernhard Rosenkraenzer 2000-12-30 18:00:26 UTC
Problem still present in 4.0.2-0.3 (in our CVS), haven't tried the current 
XFree86 CVS tree yet.

The problem is not hardware specific; I can reproduce it on an ATI card, as 

Comment 3 Bernhard Rosenkraenzer 2001-01-04 14:49:08 UTC
Still happens with an XFree86 CVS checkout from 2001/01/01.
Doesn't seem to happen for other distributions though (at least a couple of
people on kde-devel claim 4.0.2 works for them); might be a compiler or glibc
interoperability issue.

Comment 4 Bernhard Rosenkraenzer 2001-01-08 15:11:46 UTC
*** Bug 23575 has been marked as a duplicate of this bug. ***

Comment 5 Bernhard Rosenkraenzer 2001-01-08 15:13:47 UTC
Mike: Please take a look at Bug 23575 - it has some additional details on this

Comment 6 Will Newton 2001-01-11 02:13:40 UTC
This also bit me. It is unchanged with 1.x or 2.x versions of freetype.
It looks like an xfs problem. ltrace on xfs seems to stop truetype fonts being
displyed, wierd.

Comment 7 Bill Crawford 2001-01-11 02:23:29 UTC
It doesn' t happen on my machine here at home, only the PII-II at work :(
More or less the same fonts, too, AFAIK ...
Anyway am running on a build of 4.0.2 (Mike has my .spec and patches for it) and
it generally works fine here.

Comment 8 Will Newton 2001-01-11 21:23:09 UTC
On my Athlon system using gcc 2.96-69 from Rawhide it still crashes.
XFree was compiled with -march=i386 and -mcpu=i686.
I'll try and track this down, but xfs seems to report very little via syslog.

Comment 9 Will Newton 2001-01-15 02:01:16 UTC
More info:

The crash is caused by a SIGSEGV in xfs whilst doing I/O on the following

xfs         870     root    6u  unix 0xc6922500                8407

I also get this in ~/.xsession-errors:

QSocketNotifier: Multiple socket notifiers for same socket 6 and type read

No mention of whether this is an error state.

Comment 10 Bill Crawford 2001-01-15 02:08:32 UTC
I'm beginning to suspect there's more than one bug here :7/

There's been a thread of the Xpert list about xtt (and xfs) having a problem
with certain TrueType fonts but that doesn't quite gibe with someone getting an
I/O error on the socket.

My report above that it worked here but not at work turns out to be a mistaken
assumption on my part; I have some extra fonts at work, and I use them in

Comment 11 leonb 2001-01-20 17:46:23 UTC
Porgram ttmkfont also crashes (SEGV)
That makes a simpler starting point to investigate

Comment 12 Bernhard Rosenkraenzer 2001-01-20 17:52:46 UTC
The ttmkfdir crash has nothing to do with this problem. It's a compiler bug
(currently being worked on), and worked around in freetype-2.0.1-4.

Since ttmkfdir is C++ and the construct g++ is miscompiling is a rarely-used C++
construct, this is almost certainly not related to the xfs (plain C) bug.

Comment 13 Will Newton 2001-01-28 02:50:48 UTC

This bug still persists.

If anyone has any suggestions how I can help track this one down, I would really like it 

Comment 14 leonb 2001-02-02 21:05:21 UTC
Got XFree-4.02 (DRI CVS) to work properly. (attached fix)
It sems that not every font has a valid encoding pointer,
especially when using truetype-raw or unicode encoding.

- Leon Bottou <leonb@research.att.com>

P.S. :  How can I obtain permission to rsync rawhide ?  ;-)

Index: ftfuncs.c
RCS file: /cvsroot/dri/xc/xc/lib/font/FreeType/ftfuncs.c,v
retrieving revision
diff -c -r1.1.1.8 ftfuncs.c
*** ftfuncs.c	2000/11/30 17:30:56
--- ftfuncs.c	2001/02/02 20:09:42
*** 1004,1011 ****
    /* Only pass the default glyph if there is no first index */
    if(idx==0 &&
       (code != 0 ||
!       (font->mapping.encoding->first != 0 || 
!        font->mapping.encoding->first_col != 0))) {
      return Successful;
    } else {
--- 1004,1012 ----
    /* Only pass the default glyph if there is no first index */
    if(idx==0 &&
       (code != 0 ||
!       (font->mapping.encoding &&
!        (font->mapping.encoding->first != 0 || 
!         font->mapping.encoding->first_col != 0)))) {
      return Successful;
    } else {

Comment 15 Will Newton 2001-02-03 20:11:08 UTC
Sorry, this patch won't apply to XFree-4.0.2-6 RPM. I can't find even similar 
code in ftfuncs.c.

xc/lib/font/FreeType/ftfuncs.c,v 1.14 2000/04/05 18:13:24 dawes

The bug is still in existance.

Comment 16 leonb 2001-02-05 15:43:37 UTC
This code also exists in the XFree CVS.
That is revision 1.16 of ftfunc.c that belongs to XFree release 4.0.2
Revision 1.14 belongs to XFree-4.0.1 not 4.0.2.


bash-2.04$ cvs update -rxf-4_0_2 ftfuncs.c 
P ftfuncs.c
bash-2.04$ tail +1005 ftfuncs.c | head -5
  if(idx==0 &&
     (code != 0 ||
      (font->mapping.encoding->first != 0 || 
       font->mapping.encoding->first_col != 0))) {

Comment 17 Bernhard Rosenkraenzer 2001-02-06 18:37:39 UTC
*** Bug 26070 has been marked as a duplicate of this bug. ***

Comment 18 Bernhard Rosenkraenzer 2001-02-07 22:35:44 UTC
The patch doesn't fix it, and the problem is still present in the current CVS 
HEAD branch of XFree86.

Comment 19 leonb 2001-02-08 01:02:16 UTC
Strange: the patch fixed it on my computer. 
I was able to install all the usual TT fonts and I am using them right now.

The obvious difference might be that I simply compiled X with "make World" and 
installed it over the existing files.  Doing so replaces two library files that
come from two different binary packages:

  /usr/X11R6/lib/libXfont.so.1.3			(comes with XFree86-libs)
  /usr/X11R6/lib/modules/fonts/libfreetype.a		(comes with XFree86-xfs)

File "libfreetype.a" is the loadable X server module for tt fonts.  
This file is also used during the X building process to generate "libXfont.so".
That means that "libXfont.so" contains a copy of "libfreetype.a".

Program "xfs" dynamically links with "libXfont.so" and disregard
Yet reinstalling the binary rpm XFree86-xfs will not update libXfont.so
and therefore will not fix the problem.

- Leon <leonb@research.att.com>

I just checked the fonts in ttfonts.tar.bz2 and they work fine.
Note that the xfs binary I am using comes from rawhide.
But "libXfont.so" is different.  
I can email my binary if you want to make a quick check.

Comment 20 Bernhard Rosenkraenzer 2001-02-08 23:47:32 UTC
Please attach your binaries to the bug. I've updated the system correctly, but
it's not entirely impossible that this is caused by a compiler bug.

Comment 21 Tim Waugh 2001-02-09 10:22:40 UTC
I just replaced the xfs binary and the libXfont.so.1.3 library on my test
machine with ones plucked from a -O0 -march=i386 -mcpu=i386 build and restarted

ttmkfdir never has segfaulted for me.  xfs did before and still does.

Comment 22 Bernhard Rosenkraenzer 2001-02-12 19:42:14 UTC
Problem still present in 4.0.2-7 and current XFree86 HEAD branch

Comment 23 Bernhard Rosenkraenzer 2001-02-17 15:28:23 UTC
The problem is not specific to xfs - turning off xfs and adding the TrueType 
font path to /etc/X11/XF86Config-4 directly will crash the X server as soon as 
a TrueType font is accessed.

Comment 24 Mike A. Harris 2001-02-19 07:43:07 UTC
I have just added a patch to XFree86-4.0.2-9.1.25 which is building
currently.  It is a possible fix for this xfs crashing problem.
It is from the XFree guys, and aparently is working for some people.
Can you try it out bero, and if it works, we can ship this fix in our next
public release.  If it doesn't, I truely have no idea what the problem is.
After examining the code for xfs though, and the patch, it seems that it
should work though IMHO...  The fix is similar to what was proposed above
in ft_funcs.c, but is a bit larger patch.  I've heard others on the lists
say that it does fix the problem.  If it does not, I'd really like to know
why.  I haven't been able to crash X with TT fonts after applying, so if
someone still can, I need details of the system at hand.

Again though, this fixup is not currently public, so please be patient. I
will be releasing a -10 release before long.

Comment 25 Bernhard Rosenkraenzer 2001-02-22 17:31:41 UTC
Still happens for me in 9.2.

The system is installed from a full 7.1+7.1test tree; i686 kernel and glibc, 
Dual-Pentium III-450 [problem occurs when booting a UP kernel, as well, so 
it's not an SMP issue], 384 MB RAM, Matrox G200 8MB graphics card, 1024x768, 
24 bpp mode

The problem becomes more obvious if you turn off xfs and list the font paths 
(including the TT one) in XF86config-4 directly - that way, xfontsel crashes 
your X server as soon as you try to use a font in the "macromedia" foundry.

Comment 26 Tim Waugh 2001-03-13 09:19:54 UTC
Leon's patch fixes the problem for me.  -12.1 fails, -12.1+leon works.  I'll 
attach what I used so that there's no browser mess.

Comment 27 Tim Waugh 2001-03-13 09:20:49 UTC
Created attachment 12565 [details]

Comment 28 Tim Waugh 2001-03-13 09:22:01 UTC
Bero, when you tested it, you restart XFS _and_ X, right?  If it still crashes 
could you get a backtrace from gdb attached to xfs?  RPMs in my home directory.

Comment 29 Bernhard Rosenkraenzer 2001-03-15 13:33:05 UTC
*** Bug 31471 has been marked as a duplicate of this bug. ***

Comment 30 Bernhard Rosenkraenzer 2001-03-15 17:52:14 UTC
12.1 with the patch doesn't crash xfs anymore.

However, the fonts still won't work (they're displayed in the font list, but 
trying to write something in them simply uses a different font).

The font files are ok - they work as soon as you turn on antialiasing (which 
doesn't use xfs).

Also, the xfs init script nukes TrueType fonts.dir files (you can't use 
mkfontdir on TrueType).

ttmkfdir . >fonts.scale
followed by a mkfontdir call should probably be changed to

ttmkfdir . >fonts.scale
ln fonts.scale fonts.dir

Comment 31 Sammy 2001-03-15 19:28:16 UTC
One thing with running ttmkfdir:

   Many TT fonts don't contain a full character set. ttmkfdir by default
   tolerates max 5 missing characters. This you can easily change by 
        ttmkfdir -m 100 -o fonts.scale
   which tells ttmkfdir to tolerate up to 100 missing characters in a font, 
   and write the output to fonts.scale. This is useful if you know a font to 
   be very limited - often the case with decorative fonts. If you make a new
   fonts.scale file this way, remember to "reverse" it (tac fonts.scale >
   fonts.dir), move the number-entry from bottom to top, and then copy it over
   the existing fonts.dir. 

Comment 32 Will Newton 2001-04-01 18:31:32 UTC
This is fixed in 4.0.3-1 for me. I think this bug can be closed.

Note You need to log in before you can comment on or make changes to this bug.