Description of problem: Some GNOME programs (such as nautilus) fail at start with this: The program 'nautilus' 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)'. Version-Release number of selected component (if applicable): gtk2-2.12.5-1.fc9.x86_64 cairo-1.5.4-1.fc9.x86_64 How reproducible: Always, but only on one system. Steps to Reproduce: 1. Open gnome-terminal 2. Run nautilus Actual results: Error, program does not work Expected results: Program works Additional info: I don't know what component is at fault, most likely it's not actually Gtk2. Maybe Cairo? 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. This started relatively recently, but the yum log is not very helpful, there was a big chunk of updates after the holidays. The ltrace is not very informative either: g_direct_hash(0x97cb30, 0x97cb30, 0xb12aa0, 0xb39808, 0) = 0x97cb30 g_type_check_instance_cast(0xa8e010, 0xa849a0, 0x3f4b410ad8, 0, 0x326da413c8) = 0xa8e010 gdk_cursor_new(150, 0xa849a0, 0xa849a0, 918279, 0x326da413c8) = 0xb1e870 gtk_widget_get_type(0x3f4ab59a10, 16, 0xb1e870, 16, 0) = 0x9af030 g_type_check_instance_cast(0xa8e010, 0x9af030, 0xb1e870, 16, 0) = 0xa8e010 gdk_window_set_cursor(0x97d640, 0xb1e870, 0x9af030, 393731, 0) = 0xb0e3e0 gdk_cursor_unref(0xb1e870, 0, 0xb1e870, 0, 0x96f298) = 1 gdk_atom_intern(0x4ebc94, 0, 1, 0, 0x96f298) = 113 gdk_x11_xatom_to_atom(4, 0, 114, 163, 0x504f544b534544) = 4 gdk_atom_intern(0x4ebcb0, 0, 1, 917505, 0x504f544b534544) = 91 gdk_property_change(0x97d640, 91, 4, 32, 0 <unfinished ...> g_direct_hash(91, 91, 1, 917505, 0) = 91 g_direct_hash(113, 113, 1, 917505, 0) = 113 The program 'nautilus' 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 333 error_code 15 request_code 45 minor_code 0)
> 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 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).