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
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
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):
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
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:
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
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
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.