From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040625 Description of problem: When mkfontdir runs on a large directory I have containing Type 1 Adobe Font Folio fonts, it segfaults about half way through. strace'ing mkfontdir didn't reveal anything obvious enough for me to report here. All incantations of mkfontdir crash, whether called by /etc/rc.d/init.d/xfs, explicitly from the command line, etc. This symptom exhibited itself a week or so ago, but disappeared after an update. It seems to have been reintroduced as of about two days ago. The last time I had similar problems, strace showed mkfontdir segfaulting at a different point in the search than where it now segfaults. Now, however, programs seem to be calling mkfontdir (or something along these lines). For example, when I try to open sound-juicer, it crashes while trying to load. When strace'ing sound-juicer, it begins to act just like mkfontdir -- it goes through all the fonts, examining them, and crashes mid-way through. I can NFS mount the Font Folio directory on my other computers running older versions of Fedora Core xorg-x11, and mkfontdir completes its operations successfully. So it's not as if any of the Font Folio files are newly corrupted. Version-Release number of selected component (if applicable): xorg-x11-6.8.1-4 How reproducible: Always Steps to Reproduce: 1. Update computer to newest xorg-x11 2. Add the Font Folio folder to X's font configuration 3. Run 'mkfontdir', 'service xfs restart', or open particular GNOME applications (i.e., sound-juicer) and watch things crash Additional info: I can't get X to open with this problem. The GNOME splash graphic comes up, but it hangs at that point for a while, then X exits. After the update which broke font functionality, but before I restarted X, a whole host of GNOME applications quite working because they insisted on scanning the font folders and crashing.
Downgrading from Rawhide to the following packages fixed most of the font problems I was experiencing: xorg-x11-6.8.0-4 freetype-2.1.7-4 fontconfig-2.2.3-2 fc-cache, mkfontdir, etc. no longer segfault After the downgrade, however, rhgb, gdm, and gnome-session all take an extremely long time to start up. Once you've waited long enough for your GNOME session to start, the rest of the experience in X seems back to normal.
I've upgraded xorg-x11 and fontconfig to Rawhide (xorg-x11-6.8.1-4, fontconfig-2.2.3-4), and the segfault problems haven't come back. I'm pretty sure it's the new freetype causing the problems, so I've moved this to a bug in the freetype component. Since downgrading in my previous comment and since upgrading xorg-x11, I have been having one small problem with the font subsystem confusing a few fonts (particularly noticable when using a web browser). I haven't restarted X or xfs since upgrading fontconfig, however, so I'll post a screenshot if I'm still having the font confusion problem after committing this bug update and restarting X/xfs.
A few fonts are still being confused by the font subsystem. See the attached screenshot for details. Notice the weird font being used in the Slashdot headings. (The font confusion problem started after the initial downgrade to get X working again, and it still persists.) rhgb, gdm, and gnome-session are still taking a longer-than-normal amount of time to start up. It was taking much longer after I'd downgraded everything two days ago. Now that I've updated xorg-x11 and fontconfig to Rawhide, things are starting up a bit faster than last time, but it's still an abnormally long wait for things to get going.
Created attachment 104752 [details] Screenshot of fonts being confused by the font subsystem
Your startup times may improve if you run fc-cache as root. Do the crashes happen on any particular fonts, or is it a new font each time? If it happens only on particular fonts, which ones? The font mismatching seems most likely to be a fontconfig issue to me. Could you file a fontconfig bug at http://bugs.freedesktop.org with component "fontconfig". specifying what font you were expecting to get and what font you are actually getting. If you have created a .fonts.conf file in your home directory or otherwise changed the fontconfig directory, please make sure you are attaching that information.
I agree that this appears to be either a freetype bug, or perhaps something relying on internal freetype interfaces which have possibly changed (that happens far too often). We do not have legal access to these proprietary fonts however, but can you determine which specific fonts cause this problem? That might help to narrow the problem down.
Moving off of FC3Target. Marking as NEEDINFO. The long-time-to-start and font confusion problems are likely because fc-cache is also having problems with these fonts.
Closing per lack of response to previous request for information. This bug was originally filed against FC3 and has remained in NEEDINFO state for quite some time. Many packages and bugfixes have been made since the last substantive bug report. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier.