Hide Forgot
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.
Created attachment 6576 [details] Sample TrueType fonts (from OpenOffice) to reproduce this
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 well.
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.
*** Bug 23575 has been marked as a duplicate of this bug. ***
Mike: Please take a look at Bug 23575 - it has some additional details on this issue.
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.
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.
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.
More info: The crash is caused by a SIGSEGV in xfs whilst doing I/O on the following socket: xfs 870 root 6u unix 0xc6922500 8407 /tmp/.font-unix/fs7100 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.
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 WindowMaker.
Porgram ttmkfont also crashes (SEGV) That makes a simpler starting point to investigate
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.
gcc-2.96-71 XFree86-4.0.2-1 freetype-2.0.1-4 This bug still persists. If anyone has any suggestions how I can help track this one down, I would really like it killed.
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 1.1.1.8 diff -c -r1.1.1.8 ftfuncs.c *** ftfuncs.c 2000/11/30 17:30:56 1.1.1.8 --- 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))) { *g=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)))) { *g=0; return Successful; } else {
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.
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. -L. 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))) { *g=0;
*** Bug 26070 has been marked as a duplicate of this bug. ***
The patch doesn't fix it, and the problem is still present in the current CVS HEAD branch of XFree86.
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 normally 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 "libfreetype.a". Yet reinstalling the binary rpm XFree86-xfs will not update libXfont.so and therefore will not fix the problem. - Leon <leonb@research.att.com> Note: 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.
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.
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 xfs. ttmkfdir never has segfaulted for me. xfs did before and still does.
Problem still present in 4.0.2-7 and current XFree86 HEAD branch
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.
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.
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.
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.
Created attachment 12565 [details] XFree86-4.0.2-xfscrash.patch
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.
*** Bug 31471 has been marked as a duplicate of this bug. ***
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
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 running: 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.
This is fixed in 4.0.3-1 for me. I think this bug can be closed.