Bug 375131

Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 255991 [details]
X config file

Created attachment 256001 [details]
X log without config file

Created attachment 256011 [details]
X log with config file

What is different on this machine compared to other machines I have where xfs
seems to behave, is that I installed "user fonts" some time ago using the fonts
kioslave.

Unfortunately, something (don't know what) I did yesterday caused the abort to
go away. However, I now loose all "system" fonts after a suspend / resume cycle
(pm-suspend on the console). I need to restart xfs after resuming to regain all
fonts.

I have a similar issue with a x86_64 installation.
In this system xawtv seems to crash xfs.
What happens is as follow: xawtv is started (from terminal, so it can output
something), it waits and waits until it refuses to start due to missing fonts.
At this point xfs is crashed and it needs to be restarted.
Note that typing "service xfs restart" while xawtv is waiting will cause xawtv
to succeed and proceed as usual.
Further note, at shutdown, sometimes, stopping xfs fails (xfs is dead, I
presume), even without having used xawtv.
In these cases, I could see two possible causes, one is tvtime (maybe it shares
something with xawtv), the other is gnome-system-log, which crashes by its own
while selecting a different log file (so, maybe connected to xfs).

I'll try to verify if any of these two causes xfs to crash (or something else).

bye,

pg

One thing I forgot.
Checking with "symlinks -v /etc/X11/fontpath.d" returns some "dangling" links, I
do not know if this is correct.

A quick check with gnome-system-log (but on different hardware) seems to exclude
it as cause for xfs crash.

Piergiorgio, does it happen for you always, i.e. even after a full reboot, or 
only after suspend-resume? Also, did you ever install fonts as user?

For me, it only happens on the machine I once installed fonts as normal user 
using the fonts kioslave, and suspend-resume seems to be necessary to trigger 
it.

After about half of the suspend-resume cycles, xfs "just" looses all system 
fonts, but does not crash. The other half of the cycles it has all the fonts, 
but crashes often, eg. also after xlsfonts.

The dangling symlinks in /etc/X11/fontpath.d seem to be caused by the 
migration script not stripping options like ":unscaled" from the destination 
directory. I also thought it could have an influence, so I manually corrected 
that, but that did not help.

For what I have experienced so far, it happens with xawtv always and sometimes I
noticed the non-working xfs at shutdown, but, right now, I cannot say what
causes the latter.
Suspend-resume I did not try and the font install method was always the default
one, i.e. rpm.
The xlsfonts command does not seems to have influence, but I'll try it again.

I can reproduce this crash when fonts-japanese-0.20061016-12.fc8 is installed.

When I have fonts-japanese-0.20061016-12.fc8 installed, starting emacs results
in xfs blowing up.

Uninstalling fonts-japanese eliminates this crash.

Program received signal SIGABRT, Aborted.
0x0000003c51c30ec5 in raise () from /lib64/libc.so.6
(gdb) where
#0  0x0000003c51c30ec5 in raise () from /lib64/libc.so.6
#1  0x0000003c51c32970 in abort () from /lib64/libc.so.6
#2  0x000000000040961c in do_list_fonts_with_info (client=0x6229a0, 
    data=0x7fb6e0) at difs/fonts.c:1290
#3  0x0000000000409a10 in StartListFontsWithInfo (client=0x6229a0, length=54, 
    pattern=0x8 <Address 0x8 out of bounds>, maxNames=1) at difs/fonts.c:1382
#4  0x000000000040632c in ProcListFontsWithXInfo (client=0x228)
    at difs/dispatch.c:818
#5  0x0000000000406a4b in Dispatch () at difs/dispatch.c:149
#6  0x000000000040b3df in main (argc=<value optimized out>, 
    argv=<value optimized out>) at difs/main.c:156
#7  0x0000003c51c1e074 in __libc_start_main () from /lib64/libc.so.6
#8  0x0000000000402e69 in _start ()


dirs/fonts.c:

1284                    fsfree(fontInfo.isStringProp);
1285                }
1286                fsfree(prop_info);
1287
1288                --cPtr->current.max_names;
1289                if (cPtr->current.max_names < 0)
1290                    abort();
                        ********

That's the crash.

strace shows the file that xfs chokes on:

stat("/etc/X11/fontpath.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/share/X11/fonts/misc/7x14B-ISO8859-1.pcf.gz", O_RDONLY) = 6
read(6,
"\37\213\10\0\3207\323F\0\3\355\234{t\24\327}\307\277\332\207y\211\367K\200\0\361~.\10\f"...,
8192) = 4683
read(6, "", 8192)                       = 0
close(6)                                = 0
open("/usr/share/fonts/japanese/misc/7x14ab.pcf.gz", O_RDONLY) = 6
read(6,
"\37\213\10\0uO\372F\2\3\355\\it\24\327\231\375$\1bi\366\255\1\1b_\333\221z\267"...,
8192) = 4225
read(6, "", 8192)                       = 0
close(6)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(768, 768, SIGABRT)               = 0
--- SIGABRT (Aborted) @ 0 (0) ---
Process 768 detached

I have the same problem with xfs dying when running emacs (which then fails with
"No fonts found").  Removing fonts-japanese fixed the problem.  The only strange
thing is that xfs was working fine after upgrading to Fedora 8.  It just started
failing after restarting the machine after some not-obviously-related updates.

I do not have fonts-japanese installed, I tried to install and uninstall them
(just to check if something strange happens), but it did not help.

Other test was to start xawtv from command line and restart xfs, with "service
xfs start", until xawtv itself start.
Output of this was:

 This is xawtv-3.95, running on Linux/x86_64 (2.6.23.1-49.fc8)
xinerama 0: 1024x768+0+0
Warning: Missing charsets in String to FontSet conversion
Warning: Cannot convert string
"-*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,          
-*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,         
-gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*,       
-efont-biwidth-bold-r-normal--16-*-*-*-*-*-*-*,                
-*-*-bold-r-normal-*-16-*-*-*-m-*-*-*,                
-*-*-bold-r-normal-*-16-*-*-*-c-*-*-*,                        
-*-*-*-*-*-*-16-*-*-*-*-*-*-*,*" to type FontSet
Warning: Missing charsets in String to FontSet conversion
Warning: Cannot convert string "-*-bitstream vera
sans-medium-r-normal--39-*-*-*-*-*-*-*,            -*-luxi
sans-medium-r-normal--39-*-*-*-*-*-*-*,                          
-*-*-r-normal--39-*-*-*-*-*-*-*,                               
-*-*-*-*--39-*-*-*-*-*-*-*,*" to type FontSet
Warning: Missing charsets in String to FontSet conversion
Warning: Cannot convert string
"-*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,          
-*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*,         
-gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*,       
-efont-biwidth-bold-r-normal--16-*-*-*-*-*-*-*,                
-*-*-bold-r-normal-*-16-*-*-*-m-*-*-*,                
-*-*-bold-r-normal-*-16-*-*-*-c-*-*-*,                        
-*-*-*-*-*-*-16-*-*-*-*-*-*-*, *" to type FontSet

Could be useful to strace xawtv?

I have a machine around here where xfs is regularly killed by
starting firefox.  Attaching strace to xfs shows after firefox
started (full strace output available if needed):
......
open("/usr/share/X11/fonts/misc/7x14B-ISO8859-1.pcf.gz", O_RDONLY) = 6
read(6,
"\37\213\10\0\3207\323F\0\3\355\234{t\24\327}\307\277\332\207y\211\367K\200\0\361~.\10\f"...,
8192) = 4683
read(6, "", 8192)                       = 0
brk(0x9589000)                          = 0x9589000
brk(0x9581000)                          = 0x9581000
close(6)                                = 0
open("/usr/share/fonts/japanese/misc/7x14ab.pcf.gz", O_RDONLY) = 6
read(6,
"\37\213\10\0uO\372F\2\3\355\\it\24\327\231\375$\1bi\366\255\1\1b_\333\221z\267"...,
8192) = 4225
read(6, "", 8192)                       = 0
close(6)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(2118, 2118, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---

With the above many other programs will refuse to start,
or segfault or will misbehave making desktop practically unusable.

After a removal of /etc/X11/fontpath.d/fonts-japanese link it is
possible now to start firefox without killing xfs.

In the past I already run into a still open problem which seemed
to be triggered by a presence of fonts-japanese.  See bug #210718
and the second comment there in particular.  Chances are that
underlying causes are the same.

Unfortunately the situation definitely deteriorated during past
year.  AFAICS 'texdoctk' in F8 immediately segfaults does not
matter if a display is local or remote.  The problem here is
definitely fontconfig but upstream closed the issue blaming some
unspecified faults in the application and nobody wants to tell
what these alleged faults can be or where the expected behaviour
is documented.

BTW - as it happens on the machine in question was just performed
a sixteen hours run of 'memtest'.  Zero errors from that.

I have now here i386 installation of F8 on which xfs is reliably
killed, if 'fonts-japanese' are present in /etc/X11/fontpath.d/,
with xfontsel, xfd or emacs.  This time it does not seem to be easy
to achieve that with firefox; it may depend on font choices.

With xorg-x11-xfs-debuginfo installed and after attaching gdb
to xfs I see traces like that (more details attached):

Program received signal SIGABRT, Aborted.
0x00110402 in __kernel_vsyscall ()
(gdb) where
#0  0x00110402 in __kernel_vsyscall ()
#1  0x00ae0690 in raise () from /lib/libc.so.6
#2  0x00ae1f91 in abort () from /lib/libc.so.6
#3  0x08050862 in do_list_fonts_with_info (client=0x94c81a8, data=0x96e4a58)
    at difs/fonts.c:1290
#4  0x08050c0f in StartListFontsWithInfo (client=0x94c81a8, length=54,
    pattern=0x9616ff0 "-misc-fixed-bold-r-normal--13-120-75-75-c-70-iso8859-1",
maxNames=1) at difs/fonts.c:1382
#5  0x0804d500 in ProcListFontsWithXInfo (client=0x94c81a8)
    at difs/dispatch.c:818
#6  0x0804dc9f in Dispatch () at difs/dispatch.c:149
#7  0x08052536 in main (argc=Cannot access memory at address 0x2639
) at difs/main.c:156
#8  0x00acd390 in __libc_start_main () from /lib/libc.so.6
#9  0x0804a1f1 in _start ()

although another time I may see

pattern=0x9c44bc0
"-misc-fixed-bold-r-normal--14-130-75-75-c-70-iso8859-1-ISO8859-1\0201\002"
and who knows what else.

Taking out /etc/X11/fontpath.d/fonts-japanese makes the problem
disappear; at least for now but I have seen that before and that
only masked an issue for a while.

Once xfs aborted restarting it is not good enough.  The whole
session, or maybe even gdm, needs to be restarted before things start
to work again.

Created attachment 286451 [details]
trace from gdb attched to xfs on Fedora 8 installation

I should add that in gdb attempts to print variable 'stuff'
in frame 5 end up with "Cannot access memory at address 0xYYYY"
where "0xYYYY" is the same address which shows up in 
"argc=Cannot ..." message from frame 7.  That address is different
on different occasions but invariably bad.

I see exactly the same backtrace as comment #10 (even as far as the pointer
value 0x8 for pattern in frame 3)

Starting kaffeine seems to be the most frequent cause for xfs aborting.

I don't have japanese fonts installed.  I get this strace:

gettimeofday({1199032621, 193188}, NULL) = 0
read(5, "\v\1\3\0d\0d\0x\0\0\7\16\0\22\0\1\0\0\0<\0\0\0-adobe-u"..., 4096) = 84
stat("/etc/X11/fontpath.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/share/X11/fonts/Type1/UTRG____.pfa", O_RDONLY) = 6
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=72354, ...}) = 0
mmap(NULL, 72354, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2aaaaaaad000
close(6)                                = 0
brk(0x928000)                           = 0x928000
open("/usr/share/fonts/default/ghostscript/putr.pfa", O_RDONLY) = 6
fcntl(6, F_SETFD, FD_CLOEXEC)           = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=72354, ...}) = 0
mmap(NULL, 72354, PROT_READ, MAP_PRIVATE, 6, 0) = 0x2aaaaacdb000
close(6)                                = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid()                                = 3152
tgkill(3152, 3152, SIGABRT)             = 0
--- SIGABRT (Aborted) @ 0 (0) ---


This abort is *very* common, it happens at least once a day. 

I've just tried to find xorg-x11-xfs-1.0.5-1.fc8.src.rpm but it doesn't seem to
be on the mirrors I've checked ... what package is it built from?

> I don't have japanese fonts installed.

These happen to be a trigger which shows up very often.  I doubt
very much that anything is wrong with these.  Only that they quite
often show up in "unlucky" configurations and as it happens sometimes
removing those helps to hide the bug.  As noted elsewhere I have
seen sometnhing similar in other configurations too.  I still do
not know where the problem is but I strongly suspect that
'fontconfig' libraries are the real issue.

valgrind shows a number of problems including this one related to the abort:

==3610== Conditional jump or move depends on uninitialised value(s)
==3610==    at 0x32F821D8A3: (within /usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x32F821E6A7: (within /usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x32F821F586: (within /usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x32F82241A0: (within /usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x32F8224AEA: (within /usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x32F82190A9: FontFileListNextFontWithInfo (in
/usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x32F821C725: (within /usr/lib64/libXfont.so.1.4.1)
==3610==    by 0x4091E9: do_list_fonts_with_info (fonts.c:1154)
==3610==    by 0x409A0F: StartListFontsWithInfo (fonts.c:1382)
==3610==    by 0x40632B: ProcListFontsWithXInfo (dispatch.c:818)
==3610==    by 0x406A4A: Dispatch (dispatch.c:149)
==3610==    by 0x40B3DE: main (main.c:156)

It looks as though the clientPtr passed to ProcListFontsWithXInfo is bad
sometimes and that later leads to the abort.  However, in other cases (e.g. the
stack traces in comment #15 and the original report) the pointer is valid but
still aborts.

I can reproduce the problem with the upstream xfs package but haven't tried to
debug it.

Created attachment 290887 [details]
keepalive script for xfs

Since this makes my system pretty unusable and the bug assignee hasn't
commented since asking for the OP's config, I got sick of waiting for a stable
system and hacked around this very annoying bug.
Save this attachment somewhere e.g. /usr/local/bin/xfs, make it executable,
then change line 68 in /etc/init.d/xfs to use the new script:

daemon /usr/local/bin/xfs -droppriv -daemon

(In reply to comment #10)
> I can reproduce this crash when fonts-japanese-0.20061016-12.fc8 is installed.
> 
> When I have fonts-japanese-0.20061016-12.fc8 installed, starting emacs results
> in xfs blowing up.
> 
> Uninstalling fonts-japanese eliminates this crash.
> 

Just to add a comment, i get the exact same thing (was about to report the bug
as well). Japanese fonts cause xfs to crash.

One things i did find would cause the error to rear its head was the xscreensave
control in kde's control center.

I also tried to make a keep-alive script, but found that after about 5-6
restarts xfs would just stop working.

Just in case it helps anyone else, my current workaround is to disable xfs and
update xorg.conf with:
   FontPath     "built-ins"

Only a limited number of applications still rely on the old font system, most
have moved over to freetype/fontconfig.

It looks like that with the current rawhide, and especially after
an update to xorg-x11-server-Xorg-1.4.99.1-0.15.20080107.fc9, xfs
crashes with mostly anything and in any font configuration.
"Crashers" include programs like nautilus and gnome-panel and
take-your-pick; although gnome-terminal seems to be doing generally
fine.

After trying few failing programs X may tie itself in a knot, leaving
behind an unkillable process and with all attempts to restart ending
up with:

Fatal server error:
xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call

Putting into xorg.conf
   FontPath     "built-ins"
instead of 'FontPath     "unix/:7100"' indeed restores a semblance
of sanity.

I just noticed that in my setup even emacs crashes xfs, that's no good.
Eventually, the "built-ins" trick did work.

Now, is this OK (the "built-ins") or there will be other applications not working?
Because if everything is fine, why to bother to use xfs at all?

Kristian Høgsberg have you anything to say about this?

Thanks,

pg

> I just noticed that in my setup even emacs crashes xfs

Check comments #10, #12 and #15.

> Because if everything is fine, why to bother to use xfs at all?

If you are talking about a local display then "built-ins" look fine
(although I do not know if there an assurance somewhere that both
ways are in this situation equivalent).

If you are serving fonts to other clients that may not work too well.
See "FONT SERVER NAMES" section in 'man xfs' for examples and think
"thin clients".

(In reply to comment #26)
> > I just noticed that in my setup even emacs crashes xfs
> 
> Check comments #10, #12 and #15.

Ooops!

> If you are serving fonts to other clients that may not work too well.
> See "FONT SERVER NAMES" section in 'man xfs' for examples and think
> "thin clients".

Well, if xfs does crash, it is not serving fonts either way... :-)

There is still one thing. Could it be that, configuring xorg.conf with
"built-ins" and letting xfs anyway run, will work as well for local display?

For a remote display, still xfs will be able to crash... ehm... to serve fonts,
while locally we'll be safe...

In other words, since nobody seems to care to fix this annoying thing, would it
be possible to have a reasonable workaround?

Thanks,

pg

*** Bug 393801 has been marked as a duplicate of this bug. ***

On one of mine Fedora 8 systems, xfs crashes when I start the "konsole" application.

... and most other kde-applications.

This bug crippled my Fedora 9 Beta install.  Many applications failing all over
the place on login and after.  Using the "built-ins" fontpath has worked around
the issue.

I saw no problems with Fedora 8.

*** Bug 428466 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 430416 ***