Bug 430416 (badname-fixed-font)

> As I mentioned, it only happens on one system. I speculate that
> DirectColor visual has gone AWOL on it. Notice though, it's NOT
> an 8-bit color system, it has perfectly functional 24 and 32-bit
> TrueColor.

You'll have to find out a) what visual we are actually dealing with here and b)
where the error exactly comes from. (by running with --sync in gdb and breaking
on gdk_x_error.

It turned out not to have anything to do with any visuals. I only understood
this when I noticed that xterm fails to start too. It's something broken
with support for xfs.

If xfs is started before X starts, applications cannot find "fixed"
(they also fail to tell anything reasonable, aborting with BadName).
If I restart xfs, everything starts working.

I looked at the traffic between xfs and X with strace, and the problem
seems to be with X. The xfs just receives its commands (I only decoded
the command types in the fist byte, but it was enough), replies as
ordered. In the bad case, X just opens a client, and closes it.

Hmm, how odd. The rawhide X server is supposed to have fixed builtin nowadays.

Could it be xfs crashing somewhere?

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

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

Thanks in advance.

Created attachment 293936 [details]
xorg.conf

Created attachment 293937 [details]
Xorg.0.log

Created attachment 293938 [details]
Xorg.0.log.old

Created attachment 293939 [details]
strace from failing case

See fd 14. The X just opens xfs, does no operations, and closes.

Created attachment 293940 [details]
strace from xfs restart

Nothing interesting, X detects that socket closes and reopens
with a little busy-try loop.

Created attachment 293941 [details]
strace from working case

See fd 14. X opens xfs, then asks FS_QueryXBitmaps16, and proceeds
normally from there.

The fault is with X server. As you can see from strace, xfs works
just fine, the X server never sends any commands. I looked at libFS
and libXfont with git log, neither was changed ages. It's some kind
of ripple effect from changes elsewhere in X. Maybe it's the built-in
"fixed" which Mattias mentioned in comment #3 that does this.

Pete, thanks for the effort. Reassigning back to server.

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

It seems odd to me that this is a low priority, low severity bug.  Both Metacity
and Firefox fail to start because of this bug.  That's gotta be causing someone
beside me some pain.

The program 'firefox' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
  (Details: serial 728 error_code 15 request_code 45 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Window manager warning: xserver doesn't have 'fixed' font.
Bug in window manager: Unexpected X error: BadName (named color or font does not
 exist) serial 209 error_code 15 request_code 45 minor_code 0)
Locking assertion failure.  Backtrace:
#0 /usr/lib64/libxcb-xlib.so.0 [0x37a7c0097c]
#1 /usr/lib64/libxcb-xlib.so.0(xcb_xlib_lock+0x17) [0x37a7c00af7]
#2 /usr/lib64/libX11.so.6 [0x346764c610]
#3 /usr/lib64/libX11.so.6(XUngrabPointer+0x1a) [0x346764291a]
#4 /usr/lib64/libgdk-x11-2.0.so.0(gdk_display_pointer_ungrab+0xae) [0x31eec46356
]
#5 /usr/lib64/libgdk-x11-2.0.so.0(gdk_pointer_ungrab+0x1b) [0x31eec1bc79]
#6 /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so [0x340269b]
#7 /lib64/libc.so.6 [0x37a5c33000]
#8 /lib64/libc.so.6(gsignal+0x35) [0x37a5c32f75]
#9 /lib64/libc.so.6(abort+0x183) [0x37a5c34ae3]
#10 metacity [0x4386eb]
#11 metacity [0x422851]
#12 /usr/lib64/libX11.so.6(_XError+0xf4) [0x3467645524]
#13 /usr/lib64/libX11.so.6 [0x346764cf5f]
#14 /usr/lib64/libX11.so.6(_XEventsQueued+0x36) [0x346764d806]
#15 /usr/lib64/libX11.so.6(XFlush+0x1a) [0x3467624d8a]
#16 metacity [0x431455]
#17 metacity [0x43239c]
#18 metacity [0x41f355]
#19 metacity [0x42a9cf]
metacity: xcb_xlib.c:73: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
Multiple segmentation faults occurred; can't display error dialog

metacity-2.22.0-1.fc9.x86_64
firefox-3.0-0.38.cvs20080310.fc9.x86_64

I think very few people experience this bug, that's why it's low priority.

I am still planning to figure it out by myself, but I'm not familiar with
X codebase, so it goes slowly.

OK -- if I stop xfs and restart X with xfs not running, everything works fine.  

Maybe the quick answer is to Obsolete and stop shipping xorg-x11-xfs.  Or make
sure the update turns xfs off for users updating from older Fedora releases.  Is
this something Anaconda can do when performing an upgrade?

There are legitimate uses for xfs.  It's difficult to discern them just by
looking at the config files.  We'd rather not ship an update that breaks
people's working xfs configs if they have them.  But I'm pretty sure the release
notes for F8 suggested turning xfs off if you weren't (intentionally) using it.

(In reply to comment #17)
> There are legitimate uses for xfs.  It's difficult to discern them just by
> looking at the config files.  We'd rather not ship an update that breaks
> people's working xfs configs if they have them.  But I'm pretty sure the release
> notes for F8 suggested turning xfs off if you weren't (intentionally) using it.

I am not arguing that there are no legitimate uses of xfs. But should it be
default? Other distros (even the most progressive and on-the-bleeding-edge
Debian/stable) had no default xfs for years.

(In reply to comment #17)
> ... I'm pretty sure the release
> notes for F8 suggested turning xfs off if you weren't (intentionally) using it.

Unfortunately, I upgraded from F7 to F9 (F8 failed to install on this box), so I
missed those notes/steps.  I'm willing to bet others will do the same.

I think it would be best to ensure a working installation by disabling xfs
during the upgrade and put release notes in place that users can re-enable xfs
at their own risk.

Night mind dump:
Component -- libXfont (mostly src/fc/fserve.c)
Difference as seen in fs_read_open_font:
- At start, X hooks to unix/:7100 and immediately opens fixed and cursor
  This succeeds. While in OPEN_REPLY, in fs_read_open_font:
    bfont->flags 0x1f, what does this mean?),
    return 81 (StillWorking)
  Goes into INFO_REPLY next, etc.
- When xterm runs, we try again and fail. In fs_read_open_font:
    rep->otherid is nonzero == 78 (ID of fixed, obviously)
    return 83 (BadFontName) <=============================== woops. why?
  Goes into fs_handle_unexpected and dies
- Once we restarted xfs, in fs_read_open_font:
    rep->otherid is always zero, like right after reboot
    return 81 (StillWorking)
  Goes into INFO_REPLY next, yak yak, eventually succeeds. Every time.

I do not understand how this code works. The key to the problem _seems_
the combination of: 1. we open fixed for internal use on startup
(everything looks fine) and get ID 78, 2. xterm makes us to open fixed
again, and but xfs says "wait, what, you already have it under ID 78"
(with reply->otherid), 3. we do LookupIDByType(78, RT_NONE), find nada,
look through the list of in-progress opens, find nada again, and then
get completely confused and bail with BadName.

So, why the heck the xfs tells us our ID instead of just returning the
font as asked, from the protocol design perspective? I don't know.
How do we tell it not to keep our IDs? I don't know (but mind, we do
it a little bit later: after the xfs restart every new open brings
about a new font ID).

My current plan is to examine how we tell xfs to forget that we ever
opened fixed and cursor later (on successful opens), and retrofit this
into the startup sequence.

If anyone has a clue how this code works, I would appreciate a message.

Spent all day banging my head for a workaround to this problem until I stumbled
upon this bz.  Disabling xfs solves my problem and saves me a couple of bruises
on my forehead.

I narrowed this down a little bit more.

It turns out that two IDs are involved. One is passed as an argument
to fs_open_font, and _is not used for anything_ by the libXfont.
It's only used ouside, in the dixfonts.c (stored in as default font).
Let's call it ID 77. The other ID (78), is generated by fs_create_font
and stored in bfont->fontid, to be later looked up unsuccessfully
per comment 21.

The funny thing is, find_old_font cannot find ID 78 right when
fs_create_font returns, despite fs_create_font creating the ID
with GetNewFontClientID and storing it with StoreFontClientFont.
No surprise that it's not working later too.

At this time I'm ready to entertain wild theories, for example:
what if stubs for key functions get linked into libXfont by mistake,
so StoreFontClientFont never adds resource where find_old_font
could find it? It is a weak label in libXfont after all...
We'd never see any messages if it failed to link.

BTW, the bad linking theory is bogus, because fs_create_font returns
fontid of 78, which comes after 77 (created by code in DIX). Therefore,
libXfont's version of GetNewFontClientID must be calling correct
FakeClientID(). If so, StoreFontClientFont must be working too.

I found it. This bug is caused by a change in resource.c. The old
(1.3.0.0) code was like this:

	for (; res; res = res->next)
	    if ((res->id == id) && (res->type == rtype))
	    {
		retval = res->value;
		break;
	    }

Simple, right? The new code is like this:

    int istype = (rtype & TypeMask) && (rtype != RC_ANY);
	for (; res; res = res->next)
	    if ((res->id == id) && ((istype && res->type == rtype) ||
				    (!istype && res->type & rtype)))
		break;

The dix/dixfonts.c:StoreFontClientFont calls AddResource(id, RT_NONE, p).
But RT_NONE is zero, so... It can never be found.

Created attachment 304370 [details]
Possible fix (tested to work)

Not fixed in xorg-x11-server-Xorg-1.4.99.901-28.20080415.fc9.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

I'm changing the release back to "Rawhide", because I'm on Rawhide.
If Francis wants to track the fix in F9, he'll need to keep the bug
446576 separate (e.g. just like bugs in RHEL for the same root cause).

I am seeing this in my recently preupgraded F9.
Disabling xfs will also save my forehead some damage.

Strangely enough only one (the much slower one) of my systems upgraded displayed
huge problems eventhough both had xfs (unnecessarily) running. The other had
some oddities (PolicyKit not kicking in correctly and not being able to mount
internal partitions) but nautilus and firefox started OK.

Me and my friend upgraded our systems with yum from F8 to F9 and both have
this problem. When it will be fixed in F9? Bug 446576 is closed as a
duplicate, should I report a new one?

If it were RHEL, I would've already divorced Francis' bug forcefuly,
because that's how things are done there. For Fedora it's up to Ajax.
If fact, I don't even care. I just want the fix in git @freedesktop.

I have the same problem on a i386 machine; tried to reinstall all xirg-X11 fonts to no avail

(In reply to comment #15)
> I think very few people experience this bug, that's why it's low priority.
> 
> I am still planning to figure it out by myself, but I'm not familiar with
> X codebase, so it goes slowly.

Don't agree with this; it is particularly a problem with upgrading from F8 to
F9, so something is very broken in XFS.

(In reply to comment #34)
> I have the same problem on a i386 machine; tried to reinstall all xorg-X11 fonts to no avail

I finally removed xorg-X11-xfs, and everything works fine for me. 

(In reply to comment #35)
> Don't agree with this; it is particularly a problem with upgrading from F8 to
> F9, so something is very broken in XFS.

Would you read the bug before quoting obsolete comments? There is no
"something", the root cause is found and documented in the bug. Nothing
is wrong with XFS, the whole thing is in DIX. An unrelated change to
resource.c broke assumptions made by dixfonts.c.

Dear Mr. Zaitcev, the bug is real and should be fixed, and  don't care that "If
fact, I don't even care. I just want the fix in git @freedesktop"

Dear Mr. Zaitcev, the bug is real and should be fixed. Instead of writing "Would
you read the bug..." you could just tell your friends or coworkers to look at
this bug and fix it (you found the fix, thank you!).

This should definitely be fixed and made higher priority since it basically
brickifies previously working FC8 system after upgrade to FC9. I do not believe
that only small number of pople hit this bug.

This bug also breaks our systems running xfs on update from F8 to F9. Turning
off xfs 'fixes' the problem, although it seems a little odd to ship xfs with F9
if it's no longer required.

(In reply to comment #41)
> This bug also breaks our systems running xfs on update from F8 to F9. Turning
> off xfs 'fixes' the problem, although it seems a little odd to ship xfs with F9
> if it's no longer required.

I think it is required for some applications that some of us old-timers use,
like xemacs.

(In reply to comment #42)
> (In reply to comment #41)
> > it seems a little odd to ship xfs with F9
> > if it's no longer required.
> I think it is required for some applications that some of us old-timers use,
> like xemacs.

For core fonts? My understanding is that the X server itself handles core fonts
these days, so there's no need for xfs. I run xterm, xfig and xemacs from time
to time on another system that doesn't have xfs running.

(In reply to comment #43)

> For core fonts? My understanding is that the X server itself handles core fonts
> these days, so there's no need for xfs. I run xterm, xfig and xemacs from time
> to time on another system that doesn't have xfs running.
 
Hmm.  You're right!  I don't know if Bitstream Vera Sans Mono is a core font,
but it works.  There may still be some use for xfs, though.

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

Why bug 449166 was marked as a duplicate? Please see comment 30 - Pete Zaitcev
explicitly stated that he doesn't care if the bug is fixed in F9, and this bug
is for rawhide.

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

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

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

Isn't this bug fixed in xorg-x11-server-Xorg-1.4.99.902-3.20080612.fc9.i386?

My systems are packed for a relocation, I'll test after 7/3.

The problem still exists in
xorg-x11-server-Xorg-1.4.99.905-2.20080701.fc10.
Nerijus, what made you think that it may be fixed? The fix is not in the
upstream git yet. Nor do I see anything interesting in the RPM changelog.

(In reply to comment #52)
> The problem still exists in
> xorg-x11-server-Xorg-1.4.99.905-2.20080701.fc10.
> Nerijus, what made you think that it may be fixed?

Because firefox does start after I start X with xfs started, which didn't work before. Although I didn't do extensive testing.

> The fix is not in the upstream git yet.

Why?

> Nor do I see anything interesting in the RPM changelog.

I see:
* Kt Lie 03 2008 Adam Jackson <ajax> 1.4.99.905-2.20080702
- Today's snapshot.

* An Lie 01 2008 Adam Jackson <ajax> 1.4.99.905-1.20080701
- 1.5RC5.

And I thought the fix was already applied upstream.
Could it be the fix is applied to 1.4.99.905-2.20080702.fc9 but not to 1.4.99.905-2.20080701.fc10?

Keith Packard wrote that my patch was incorrect and sent me a different
one to test. The test was successful.
 http://lists.freedesktop.org/archives/xorg/2008-August/037837.html

Created attachment 313661 [details]
Keith's fix (tested to work)

Just to help negate the notion that this isn't a problem for most people, I'm testifying that this bug is a problem for me (I use xdmcp which depends on xfs which depends on the broken dixfonts.c).

gb

I don't know how that happened, but comment #54 has a bad link.
Here's the correct message:
 http://lists.freedesktop.org/archives/xorg/2008-August/037554.html

The attachement in comment #55 has the correct patch, fortunately.

The suggested patch works fine for us, and also solves the bug described at https://bugs.freedesktop.org/show_bug.cgi?id=18259.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The tip of the git tree is still busted, but applications in Fedora
work (e.g. xterm starts), and it's all I care about. Closing.

xorg-x11-server-Xorg-1.5.99.3-4.fc11.x86_64

BTW, the message "Warning: LookupIDByType()/SecurityLookupIDByType() are
deprecated. blah blah blah" is not triggered in Fedora. So, this bug is
worked around elsewhere (probably with built-in "fixed" now working).