From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030509 Description of problem: [1 kajtzu@d122 /usr/share/fonts/afms/adobe]% sudo gdb /usr/sbin/chkfontpath GNU gdb Red Hat Linux (5.3post-0.20021129.29rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)... (gdb) run -q -a /usr/share/fonts/afms/adobe Starting program: /usr/sbin/chkfontpath -q -a /usr/share/fonts/afms/adobe (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x001a6044 in fgets () from /lib/tls/libc.so.6 (gdb) bt #0 0x001a6044 in fgets () from /lib/tls/libc.so.6 #1 0x08048f40 in poptPrintHelp () #2 0x08049e7b in poptPrintHelp () #3 0x00159568 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) Version-Release number of selected component (if applicable): chkfontpath-1.9.9-1 How reproducible: Always Steps to Reproduce: 1. Run it 2. 3. Actual Results: Segfaults and corrupts font.cache-1 Expected Results: Shouldn't segfault Additional info:
I just installed it and it is not happening to me!
Fixed by upgrading to popt-1.8-0.69.i386.rpm (had 1.8.0-60) Works for me.
That popt update might or might not have fixed this. chkfontpath, ttmkfdir and other applications are randomly SEGV'ing. We're still trying to determine the cause. If the problem recurs, please reopen.
It is (was?) a transient problem. It doesn't happen every single time, so you could just be getting lucky. I'm going to be running a script to install and uninstall fonts nonstop and try to generate a core with full debuginfo packages installed, and try to get more info.
chkfontpath didn't seem to die anymore when I tried it scripted against all the font dirs I've got installed on my development laptop. You wouldn't happen to be able to hook me up with rawhide debuginfo packages, would you? (like is there a repository somewhere) Should I file a RFE for them? Just for the record, I'm running glibc-2.3.2-41 (i686) kernel-2.4.20-20.1.1995.2.1.nptl (i686)
Reopening until I can complete testing.
It is still reproduceable. It has about a 20% SEGV rate if ran one after the other. I believe it is kernel or glibc related. We will update this report with more info as the problem gets weeded out.
I just ran it 200 times with no crash. I have all rawhide except kernel 2.4.20-13.9
It is the "except" part, which is why you can't reproduce it. It is most likely a kernel bug. Reproduceable on every single rawhide kernel from .1988. through .2001. I debugged it last night and it SEGV's inside fgets(), however my backtrace is different than the one above. (gdb) set args -qa /usr/X11R6/lib/fonts/TTF (gdb) run Starting program: /usr/sbin/chkfontpath -qa /usr/X11R6/lib/fonts/TTF Program exited normally. (gdb) run Starting program: /usr/sbin/chkfontpath -qa /usr/X11R6/lib/fonts/TTF Program exited normally. (gdb) run Starting program: /usr/sbin/chkfontpath -qa /usr/X11R6/lib/fonts/TTF Program received signal SIGSEGV, Segmentation fault. 0x4008cd44 in fgets () from /lib/i686/libc.so.6 (gdb) bt #0 0x4008cd44 in fgets () from /lib/i686/libc.so.6 #1 0x08048f40 in readFontPath () at chkfontpath.c:134 #2 0x08049e7b in main (argc=176285808, argv=0x4015f2c0) at chkfontpath.c:406 #3 0x4003f8c7 in __libc_start_main () from /lib/i686/libc.so.6
void readFontPath(void) { FILE *f; char buf[250]; char *s, *p, *q; int catFlag = 0; int noFirstLine = 0; if (NULL == (f = fopen(XFS_CONFIGFILE, "r"))) fatalerror("%s: error opening %s\n", progName, XFS_CONFIGFILE); while ((q = s = fgets(buf, sizeof(buf), f)) != NULL) { The final line of code is line 134, and the fgets() there is what SEGVs.
I ran this through valgrind, and it shows a memory leak in libpopt, however I think that is an unrelated issue.
kernel-2.4.20-20.1.1995.2.2.nptl seems to have solved the problem.