Bug 118588

Created attachment 98633 [details]
strace of xterkm

xterm (as well as emacs, and probably anything that still uses old X
fonts) fails to start even with XFree86-4.3.0-64, and that' s on i386.

bill: thanks for the strace

lxo:  Thanks for the info also!

If this happens with XFree86-4.3.0 also, then it's probably not an
X related change.  Any chance either of you could try to narrow
down a particular package change that causes the problem to first
appear?

Also, is xfs running?

This is filed against x86_64.  lxo, are you seeing this on x86_64
as well, or on another arch?

TIA

i686, as written above.  Yes, xfs was running (I checked, and even
tried to restart it then log in again).

When I wrote `fails to start', I meant `starts but doens't even open
an X window'.  Not sure whether this is the same behavior that notting
is experiencing, he just asked me to piggyback on this bug for now.

FWIW, my xterm was started from .Xclients, and emacs was started with
a gnome-panel icon, but running them from the command line hangs just
the same.  It's not exactly that they hang: they keep on issuing
syscalls, they just don't make any progress whatsoever.

Correct, the behavior I see is that it hangs before opening a window.

I've just found out that if I set LANG=C, all of xterm, emacs and
xemacs start working again.  I've no idea of how to tell whether the
problem has to do with fonts or something else, but I thought I'd
mention this.

Also, if I ssh to localhost with X forwarding enabled and start one of
these applications, they work.  Without ssh, setting LANG to anything
other than en_US.UTF-8 works as well.

I tried running FC1's xterm, with and without LD_LIBRARY_PATH pointing
to FC1's libs, and it failed just like FC2's xterm.

I suspect this might be related: /etc/init.d/xfs restart often prints
at least one segmentation fault message.

It consistently crashes while processing /usr/X11R6/lib/X11/fonts/TTF
for me, the way it's started by the xfs init.d script, but if I
reinstall xorg-x11-truetype-fonts, the fonts files are regenerated
correctly.  Very odd, but unrelated.

The font file problem described in comment #10, I believe is due
to a bug either in ttmkfdir, or a bug in some fonts which is worked
around in the most recent version of ttmkfdir.

I've CC'd yshao for comment about this latter issue.

I believe the xterm bug reported here is due to a bug/glitch in
libXft from version 2.1.5 of Xft which got into Xorg recently.

I'll be examining this issue sometime this week hopefully, and will
report back status from my testing once available.

Thanks again for the additional info.

Please upgrade to xorg-x11-0.0.6.6-0.0.2004_03_11.8, reboot and
test to see if the problem is resolved with the various Xft/xfs
fixes in the new build, and report back if things have changed
at all.

TIA

Installed a full tree from scratch, with xorg-x11*.8, and xterm still
doesn't start (on i686) :-(

A flaw was discovered in the .8 package, which is fixed in .9, please
try the .9 package and report back.

TIA

No change with .9 :-(

It's the environment variable XMODIFIERS=@im=htt that kills xterm and
emacs.  /me wonders how/why it gets set.

I can't reproduce it, but it would be good to test im-sdk-11_4-30,
cause it fixed a home directory issue for htt, prior to -30, htt will
run as user_u:user_r:user_t, just wonder if this is releated.

service IIim stop then restart X fixes it.  Looks like xinitrc
shouldn't be setting XMODIFIERS for locales such as en_US.UTF-8.

XMODIFIERS shouldn't cause applications to hang, though
the XMODIFIERS setting does need fixing indeed: it should
only be set for locale where iiimf is useful I guess.

Following on to comment 14, I just did an en_US everything
install of test2, and I still can't reproduce this: xterm and
emacs start just fine for me (admittedly with a httx XIM status
window at the bottom).

Moved XMODIFIERS problem to bug 119240,
and sent a patch to Mike to fix it.

We would still like to know how to reproduce the
hanging XIM apps problem though...

The only thing I think I may not have mentioned before is that my
keyboard layout is us_intl.  This might conflict with IIim in ways
that cause apps to hang, but I sort of doubt notting has us_intl
selected, and he did run into the problem.  Also make sure your
environment is en_US.UTF-8, as plain en_US will *not* trigger the problem.