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 support 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): XFree86-4.3.0-2 How reproducible: Always 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: cd /tmp ls -l / > junk /opt/faximum/bin/fsasciitiff junk Actual Results: junk: [1FSIO: fatal IO error 32 (Broken pipe) on font server "tcp/localhost:7100" 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. Additional info:
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 problem. Putting in the United Linux library does still fix the problem. To ensure the files we installed are correct: XFree86-libs-4.3.0-42.i386.rpm size: 2444734 md5sum: a1949e3a12e7c585f6e933685a6addaa libXfont.so.1.4 size: 638824 md5sum: ffb75cabf6b086e3d309454edb4f56b6 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 helpful. 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 sources. 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 the problem.
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" component. 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.