Bug 430416 - (badname-fixed-font) "BadName" for "fixed" unless xfs is restarted
"BadName" for "fixed" unless xfs is restarted
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11-xfs (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
: 375131 430411 446576 449166 452568 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-27 15:46 EST by Pete Zaitcev
Modified: 2008-12-26 16:02 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-26 16:02:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
xorg.conf (2.85 KB, text/plain)
2008-02-04 15:09 EST, Pete Zaitcev
no flags Details
Xorg.0.log (36.40 KB, text/plain)
2008-02-04 15:10 EST, Pete Zaitcev
no flags Details
Xorg.0.log.old (37.01 KB, text/plain)
2008-02-04 15:10 EST, Pete Zaitcev
no flags Details
strace from failing case (17.29 KB, text/plain)
2008-02-04 15:11 EST, Pete Zaitcev
no flags Details
strace from xfs restart (5.02 KB, text/plain)
2008-02-04 15:12 EST, Pete Zaitcev
no flags Details
strace from working case (197.73 KB, text/plain)
2008-02-04 15:18 EST, Pete Zaitcev
no flags Details
Possible fix (tested to work) (824 bytes, patch)
2008-05-02 06:00 EDT, Pete Zaitcev
no flags Details | Diff
Keith's fix (tested to work) (32.72 KB, patch)
2008-08-06 23:39 EDT, Pete Zaitcev
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 18259 None None None Never

  None (edit)
Description Pete Zaitcev 2008-01-27 15:46:08 EST
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)
Comment 1 Matthias Clasen 2008-02-03 00:29:57 EST
> 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.
Comment 2 Pete Zaitcev 2008-02-03 01:55:41 EST
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.
Comment 3 Matthias Clasen 2008-02-03 07:50:35 EST
Hmm, how odd. The rawhide X server is supposed to have fixed builtin nowadays.
Comment 4 Matěj Cepl 2008-02-04 10:33:13 EST
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.
Comment 5 Pete Zaitcev 2008-02-04 15:09:42 EST
Created attachment 293936 [details]
xorg.conf
Comment 6 Pete Zaitcev 2008-02-04 15:10:17 EST
Created attachment 293937 [details]
Xorg.0.log
Comment 7 Pete Zaitcev 2008-02-04 15:10:40 EST
Created attachment 293938 [details]
Xorg.0.log.old
Comment 8 Pete Zaitcev 2008-02-04 15:11:47 EST
Created attachment 293939 [details]
strace from failing case

See fd 14. The X just opens xfs, does no operations, and closes.
Comment 9 Pete Zaitcev 2008-02-04 15:12:53 EST
Created attachment 293940 [details]
strace from xfs restart

Nothing interesting, X detects that socket closes and reopens
with a little busy-try loop.
Comment 10 Pete Zaitcev 2008-02-04 15:18:38 EST
Created attachment 293941 [details]
strace from working case

See fd 14. X opens xfs, then asks FS_QueryXBitmaps16, and proceeds
normally from there.
Comment 11 Pete Zaitcev 2008-02-04 15:23:29 EST
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.
Comment 12 Matěj Cepl 2008-02-05 09:08:46 EST
Pete, thanks for the effort. Reassigning back to server.
Comment 13 Pete Zaitcev 2008-02-08 01:17:17 EST
*** Bug 430411 has been marked as a duplicate of this bug. ***
Comment 14 Rob Riggs 2008-03-11 21:14:31 EDT
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
Comment 15 Pete Zaitcev 2008-03-11 21:57:23 EDT
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.
Comment 16 Rob Riggs 2008-03-13 09:41:30 EDT
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?
Comment 17 Adam Jackson 2008-03-13 13:10:09 EDT
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.
Comment 18 Matěj Cepl 2008-03-13 13:21:34 EDT
(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.
Comment 19 Rob Riggs 2008-03-13 19:22:11 EDT
(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.
Comment 20 Pete Zaitcev 2008-04-15 07:16:52 EDT
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.
Comment 21 Pete Zaitcev 2008-04-18 14:59:47 EDT
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.
Comment 22 Don Zickus 2008-04-23 17:23:37 EDT
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.

Comment 23 Pete Zaitcev 2008-05-01 01:42:55 EDT
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.
Comment 24 Pete Zaitcev 2008-05-01 01:55:03 EDT
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.
Comment 25 Pete Zaitcev 2008-05-02 05:58:24 EDT
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.
Comment 26 Pete Zaitcev 2008-05-02 06:00:15 EDT
Created attachment 304370 [details]
Possible fix (tested to work)
Comment 27 Pete Zaitcev 2008-05-06 21:47:00 EDT
Not fixed in xorg-x11-server-Xorg-1.4.99.901-28.20080415.fc9.
Comment 28 Bug Zapper 2008-05-14 00:54:10 EDT
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
Comment 29 Francis Kung 2008-05-15 11:49:17 EDT
*** Bug 446576 has been marked as a duplicate of this bug. ***
Comment 30 Pete Zaitcev 2008-05-15 14:59:39 EDT
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).
Comment 31 Michael Wiktowy 2008-05-17 03:21:43 EDT
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.
Comment 32 Nerijus Baliūnas 2008-05-20 08:48:10 EDT
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?
Comment 33 Pete Zaitcev 2008-05-20 15:46:33 EDT
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.
Comment 34 Hardy Mayer 2008-05-21 23:55:53 EDT
I have the same problem on a i386 machine; tried to reinstall all xirg-X11 fonts to no avail
Comment 35 Max E 2008-05-22 07:21:34 EDT
(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.
Comment 36 Hardy Mayer 2008-05-22 11:23:03 EDT
(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. 
Comment 37 Pete Zaitcev 2008-05-22 12:49:28 EDT
(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.
Comment 38 Nerijus Baliūnas 2008-05-22 21:10:25 EDT
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"
Comment 39 Nerijus Baliūnas 2008-05-22 21:20:54 EDT
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!).
Comment 40 Vladimir Kotal 2008-05-26 14:06:10 EDT
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.
Comment 41 Ben Webb 2008-06-04 18:40:46 EDT
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.
Comment 42 jonathan baron 2008-06-04 18:50:30 EDT
(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.
Comment 43 Ben Webb 2008-06-04 19:07:35 EDT
(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.
Comment 44 jonathan baron 2008-06-04 19:15:45 EDT
(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.
Comment 45 Matěj Cepl 2008-06-06 12:15:50 EDT
*** Bug 449166 has been marked as a duplicate of this bug. ***
Comment 46 Nerijus Baliūnas 2008-06-09 16:07:09 EDT
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.
Comment 47 Matěj Cepl 2008-06-25 12:49:48 EDT
*** Bug 375131 has been marked as a duplicate of this bug. ***
Comment 48 Matěj Cepl 2008-06-25 12:49:58 EDT
*** Bug 446576 has been marked as a duplicate of this bug. ***
Comment 49 Matěj Cepl 2008-06-25 12:50:17 EDT
*** Bug 452568 has been marked as a duplicate of this bug. ***
Comment 50 Nerijus Baliūnas 2008-06-25 13:31:31 EDT
Isn't this bug fixed in xorg-x11-server-Xorg-1.4.99.902-3.20080612.fc9.i386?
Comment 51 Pete Zaitcev 2008-06-25 15:52:51 EDT
My systems are packed for a relocation, I'll test after 7/3.
Comment 52 Pete Zaitcev 2008-07-26 01:03:15 EDT
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.
Comment 53 Nerijus Baliūnas 2008-08-06 17:11:13 EDT
(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@redhat.com> 1.4.99.905-2.20080702
- Today's snapshot.

* An Lie 01 2008 Adam Jackson <ajax@redhat.com> 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?
Comment 54 Pete Zaitcev 2008-08-06 23:37:39 EDT
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
Comment 55 Pete Zaitcev 2008-08-06 23:39:28 EDT
Created attachment 313661 [details]
Keith's fix (tested to work)
Comment 56 Gregory Lee Bartholomew 2008-08-26 12:35:08 EDT
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
Comment 57 Pete Zaitcev 2008-10-12 11:14:57 EDT
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.
Comment 58 Peter Åstrand 2008-11-21 03:48:18 EST
The suggested patch works fine for us, and also solves the bug described at https://bugs.freedesktop.org/show_bug.cgi?id=18259.
Comment 59 Bug Zapper 2008-11-25 21:05:34 EST
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
Comment 60 Pete Zaitcev 2008-12-26 16:02:58 EST
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).

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