Red Hat Bugzilla – Bug 103453
xfs crashes with RH9 libXfont.so.1 library, works with UnitedLinux libXfont.so.1 library
Last modified: 2005-10-31 17:00:50 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Description of problem:
With xfs and libXfont as shipped with RH9, attempts to obtain font glyphs cause
xfs to crash after between 10 - 60 requests.
Same problem does not exist with RH 7.x or 8.
Replacing the libXfont.so.1 file with one from a UnitedLinux distribution causes
xfs to work perfectly.
Problem revealed by running the Faximum FMS fax server software which contains a
utility to convert text files into TIFF-F format that uses the X11 font server
to provide the glyphs. A free licence to this software is available from
firstname.lastname@example.org for any Red Hat engineers who wish to reproduce the problem.
More research to determine cause of problem not done.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Startup X11 font server (/etc/rc.d/init.d/xfs start)
2. Install Faximum FMS for Linux (http://www.faximum.com/fms/download/)
3. Obtain activation key (http://www.faximum.com/register/)
4. Convert flat text file:
ls -l / > junk
Actual Results: junk: [1FSIO: fatal IO error 32 (Broken pipe) on font server
after 21 requests (20 known processed) with 0 events remaining.
The connection was probably broken by a server shutdown.
Expected Results: A TIFF-F file called junk.tif ought to be created.
I'm going to attach a new libXfont.so.1.4 to the bug report for you to test,
however you'll need to restore the original Red Hat XFree86 installation and
remove the SuSE library or move it into /root or somewhere first.
The libXfont.so.1 on a freshly installed system, is a symbolic link pointing
to libXfont.so.1.4, so if you've replaced that symlink with an actual library
file from SuSE, then if you install my test library, you'll still get the
SuSE library because applications will be looking for libXfont.so.1 and instead
of getting a symlink linked to libXfont.so.1, they'll get the SuSE lib. You
probably should have took the full .so.1.4 file from SuSE instead of
overwriting the symlink, which would have been saver, but no big problem for
now. Just be sure to do something like:
mv libXfont.so.1 /root/libXfont.so.1.SUSE
Then drop in the libfont.so.1.4 file I'm attaching, into /usr/X11R6/lib,
and after that, be sure to run "ldconfig". It is recommended to reboot
your system to ensure the new library is being tested properly.
Please let me know if the new library makes any difference for you.
Thanks in advance.
Created attachment 94092 [details]
/usr/X11R6/lib/libXfont.so.1.4 from XFree86 4.3.0-22.1 in rawhide
Sorry for not being clearer in my original report.
I did as you suggested, that is, saved the original libXfont.so.14 file and
replaced it with the United Linux one (from SCO Linux to be precise...just
happened to be at hand) -- did not touch the sym link.
Installed your test library on a DIFFERENT freshly installed RH9 system (so as
to avoid any possible contamination from the SCO Linux libXfont file) and
experienced the same failure. Rebooted just to be sure but no change.
Please let me know if there is anything else we can do to help.
4.3.0-32 in rawhide has a great number of fixes for libXfont, all of which
prevent SEGV and other serious problems. Please test this release on a
Severn beta system with updates applied.
In recent builds there have been additional libXfont signed/unsigned integer
related bugs which have been fixed. This should make both the X server, as
well as xfs much more stable and secure. These fixes are believed to fix
this problem for you as well.
Since there's no comment since my last suggestion, I'm assuming the last
build referenced above and/or the latest rawhide XFree86-4.3.0-40 build
must fix the problem for you now.
Closing as fixed in "RAWHIDE".
Feel free to reopen, if the problem recurs while using Fedora Core test 3 or
later with XFree86 4.3.0-40, including new details.
Apologies for not following up on this sooner -- since running the
libXfont.so.1.4 file from UnitedLinux solved the problem it was hard
to justify spending time on this immediately when other
alligators/swamps needed attention.
Anyway a customer who is trying to use RHEL 3 with our product and who
was obviously less than enthused about our work-around asked us to
look into this further :-)
So we purchased a copy of RHEL 3, reproduced the problem, downloaded
XFree86-libs-4.3.0-42.i386.rpm and found that using the
libXfont.so.1.4 file from the -42 build for RAWHIDE does not fix the
Putting in the United Linux library does still fix the problem.
To ensure the files we installed are correct:
So the ball is back in your proverbial court. We are more than willing
to do whatever we can to help including putting our RHEL3 dev sys
outside our firewall for you to access using ftp/ssh and toi repro the
problem (or, conversely, we can give you a licence for our software
which is causing the xfs daemon to crash with the bad libXfont library).
Have bumped the severity and priority up a notch as (a) we have a
customer for whom this is a P1 issue (they want to resell RHEL3
systems and cannot do so while this problem is open) and (b) we want
to qualify our software for RHEL 3.
Can you enable core dumps on your system, and get a coredump from
xfs using our latest XFree86 update for RHL 9 (or on RHEL 3)?
If you can get a backtrace from that with gdb, that would be
Also, what version of UnitedLinux did you use that this problem was
not reproduceable on, and also what version of XFree86 is installed
on that system? Please supply the version-release tag rpm provides
on the SuSE system by doing: rpm -q XFree86
I will then download their source and binaries and see if they
have some patch they're applying which is not present in upstream
Thanks in advance.
Oh, another question.. Can you provide a complete list of all
of the fonts installed on this system as a file attachment? If you
are using only Red Hat supplied fonts, and no 3rd party fonts are
installed, then this is not necessary.
This is requested just in case specific fonts are needed to trigger
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue. Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:
If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.