Bug 52764 - xdvi segfaults with FontPath order!
xdvi segfaults with FontPath order!
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-28 16:10 EDT by Sammy
Modified: 2007-04-18 12:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-15 13:50:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
local type1 font directory (14.24 MB, application/octet-stream)
2001-09-12 14:57 EDT, Sammy
no flags Details
Here is a backtrace. It's with libXaw rather than libXaw3d to see if it behaved any differently (it didn't). (1.59 KB, text/plain)
2001-10-15 13:47 EDT, Tim Waugh
no flags Details

  None (edit)
Description Sammy 2001-08-28 16:10:31 EDT
Description of Problem:


This took a while to find out! If one puts a none-bitmap font
directory as the first FontPath element in /etc/X11/XF86Config-4
file....xdvi segfaults with a message saying it could not find any
useful ISO8859-1 fonts. Even though xlsfonts lists hundreds
of iso8859-1 fonts. It may be that the buffer for font names is
filling up since what I had as the first FontPath element contained
373 Type1 fonts.

Version-Release number of selected component (if applicable):


How Reproducible:


Steps to Reproduce:
1. 
2. 
3. 

Actual Results:


Expected Results:


Additional Information:
Comment 1 Tim Waugh 2001-09-11 06:59:46 EDT
I haven't been able to reproduce this.  Could you give a more detailed 
description of how to reproduce the problem?

Thanks.
Comment 2 Sammy 2001-09-12 14:57:19 EDT
Created attachment 31677 [details]
local type1 font directory
Comment 3 Sammy 2001-09-13 14:29:32 EDT
My comments did not make it for some reason! What I was saying is that
for some reason if I put the Type1 directory that comes with XFree86
than xdvi works but if I put my local directory that contains Type1 fonts
than it comes with the message:

Warning: Unable to load any usable ISO8859-1 font
Segmentation fault

despite the fact that 100dpi etc are all listed after that. My guess is that
whatever code that is reading the fonts is crashing with the local fonts and
never continuing to the following directories in the Fontmap. X11 works fine
with that font directory. I have attached a local.tar.bz2 file earlier in case you
would like to see what is causing the problem. For example, I found that if
I include ghostscript fonts for anti-aliasing xftcache segfaults if I leave the
*.gsf files in that directory. Naturally, gsf files are not Type1 but a program
should not segfault for any case. Perhaps something like this is happening
with xdvi for these fonts as well. I guess this is not a packaging problem.
Thanks
Comment 4 Tim Waugh 2001-09-18 12:01:14 EDT
I'm afraid I still haven't been able to reproduce this problem.  Here's what I 
tried:

1. Unpack the fonts to /tmp/local.
2. Change /etc/X11/fs/config so that /tmp/local is the first directory in the 
font directory search path.
3. Restart xfs with 'service xfs restart'
4. Use xdvi to view a dvi file.

It works fine here.

Can you try 'gdb xdvi.bin', then 'run', and then when it crashes 'bt', and 
tell me what it says?
Comment 5 Sammy 2001-09-21 16:09:58 EDT
OK here it is:
==================================
$ gdb /usr/bin/xdvi.bin
GNU gdb Red Hat Linux 7.x (5.0rh-16) (MI_OUT)
Copyright 2001 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"...
(no debugging symbols found)...
(gdb) run
Starting program: /usr/bin/xdvi.bin
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Warning: Unable to load any usable ISO8859-1 font
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x40121a02 in GetnormalGC () from /usr/X11R6/lib/libXaw3d.so.7
(gdb) bt
#0  0x40121a02 in GetnormalGC () from /usr/X11R6/lib/libXaw3d.so.7
#1  0x40121c6d in Initialize () from /usr/X11R6/lib/libXaw3d.so.7
#2  0x4018ea87 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#3  0x4018ef91 in XtInitializeWidgetClass () from /usr/X11R6/lib/libXt.so.6
#4  0x4018f469 in _XtCreateWidget () from /usr/X11R6/lib/libXt.so.6
#5  0x4018f58d in XtCreateManagedWidget () from /usr/X11R6/lib/libXt.so.6
#6  0x0805dd9f in strcpy ()
#7  0x0805f090 in strcpy ()
#8  0x08052129 in strcpy ()
#9  0x0804d138 in strcpy ()
#10 0x40313507 in __libc_start_main (main=0x804c820 <strcpy+2680>, argc=1,
    ubp_av=0xbffff9e4, init=0x804b010 <_init>, fini=0x806a3b0 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9dc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)
Comment 6 Sammy 2001-09-21 16:11:26 EDT
*****One additional comment: I am NOT using xfs but have directories in
      Fontmap statements.
Comment 7 Tim Waugh 2001-09-26 09:02:24 EDT
I still can't reproduce this problem, and the backtrace doesn't give me much 
of a clue either.

I tried replacing 'FontPath "unix:/7100"' with one fontpath statement per font 
directory from /etc/X11/fs/config.  I put 'FontPath "/mnt/local"' at the 
start, and unpacked the fonts into it.  I restarted X, and invoked xdvi.

Can you please give me some more details about how your fonts are set up, so 
that I can try to copy that setup on a machine here?
Comment 8 Sammy 2001-09-26 09:28:49 EDT
I have:

    FontPath    "/usr/X11R6/lib/X11/fonts/local"
    FontPath    "/usr/X11R6/lib/X11/fonts/100dpi:unscaled"
    FontPath    "/usr/X11R6/lib/X11/fonts/75dpi:unscaled"
    FontPath    "/usr/X11R6/lib/X11/fonts/misc"
    FontPath    "/usr/X11R6/lib/X11/fonts/100dpi"
    FontPath    "/usr/X11R6/lib/X11/fonts/75dpi"
    FontPath    "/usr/share/fonts/ISO8859-9/misc"
    FontPath    "/usr/X11R6/lib/X11/fonts/Speedo"

I am using XFree86-4.1-3 from rawhide AND anti-aliasing for the Type1 and
TrueType fonts.
Comment 9 Tim Waugh 2001-09-26 10:55:00 EDT
Hunh.  Now I get this when I start X:

Could not init font path element /mnt/local, removing from list!

(/mnt/local is where I unpacked the fonts, of course.)
Comment 10 Sammy 2001-09-27 10:28:06 EDT
hmmmm...that usually happens if fonts.dir is missing but it should be there.
Does xdvi work?
Comment 11 Tim Waugh 2001-09-30 17:16:20 EDT
Yes, it does, and fonts.dir is there unchanged.  Odd.
Comment 12 Sammy 2001-10-01 09:25:16 EDT
That is odd. Do you have the type1 module loaded in XF86Config-4?
Comment 13 Tim Waugh 2001-10-15 12:52:07 EDT
No, I didn't.  Okay, now I see the same thing.  Investigating.
Comment 14 Tim Waugh 2001-10-15 13:47:56 EDT
Created attachment 34121 [details]
Here is a backtrace.  It's with libXaw rather than libXaw3d to see if it behaved any differently (it didn't).
Comment 15 Tim Waugh 2001-10-15 13:49:43 EDT
Given that 'emacs' also gives the ISO8859-1 warnings when starting under these 
circumstances, I'm given to assume that the segfault is an Xaw bug, and that the font 
warnings are some X library problem or other.  Assigning to XFree86.
Comment 16 Tim Waugh 2001-10-15 13:50:32 EDT
Mike, let me know if you need a more detailed how-to-reproduce for this.
Comment 17 Mike A. Harris 2002-03-14 13:36:00 EST
This bug should be reported instead to XFree86 upstream.  It is not a
widely reported bug, nor considered serious, as such it is given a low
priority, and stands a much higher likelyhood of being fixed if reported
upstream to XFree86.org.

You can email a bug report to xfree86@xfree86.org if you like.

Note You need to log in before you can comment on or make changes to this bug.