Bug 118588 - xterm doesn't start
Summary: xterm doesn't start
Alias: None
Product: Fedora
Classification: Fedora
Component: im-sdk   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact:
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
Reported: 2004-03-17 22:49 UTC by Bill Nottingham
Modified: 2014-03-17 02:43 UTC (History)
6 users (show)

Fixed In Version: im-sdk-11.4-31
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-03-28 03:15:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace of xterkm (61.69 KB, text/plain)
2004-03-17 22:50 UTC, Bill Nottingham
no flags Details

Description Bill Nottingham 2004-03-17 22:49:44 UTC
Upgrade to xorg-x11 .5.

xterm now hangs on startup (run from a gnome-terminal, if that matters.)

Strace attached.

Comment 1 Bill Nottingham 2004-03-17 22:50:14 UTC
Created attachment 98633 [details]
strace of xterkm

Comment 2 Alexandre Oliva 2004-03-18 16:49:54 UTC
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.

Comment 3 Mike A. Harris 2004-03-18 17:25:13 UTC
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

Also, is xfs running?

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


Comment 4 Alexandre Oliva 2004-03-18 18:00:10 UTC
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.

Comment 5 Bill Nottingham 2004-03-18 23:22:28 UTC
Correct, the behavior I see is that it hangs before opening a window.

Comment 6 Alexandre Oliva 2004-03-19 02:34:20 UTC
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.

Comment 7 Alexandre Oliva 2004-03-19 03:29:27 UTC
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.

Comment 8 Alexandre Oliva 2004-03-19 03:35:12 UTC
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.

Comment 9 Alexandre Oliva 2004-03-20 01:23:05 UTC
I suspect this might be related: /etc/init.d/xfs restart often prints
at least one segmentation fault message.

Comment 10 Alexandre Oliva 2004-03-20 04:23:12 UTC
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.

Comment 11 Mike A. Harris 2004-03-23 01:45:21 UTC
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.

Comment 12 Mike A. Harris 2004-03-23 01:47:02 UTC
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.

Comment 13 Mike A. Harris 2004-03-24 19:11:57 UTC
Please upgrade to xorg-x11-, 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.


Comment 14 Alexandre Oliva 2004-03-25 16:36:13 UTC
Installed a full tree from scratch, with xorg-x11*.8, and xterm still
doesn't start (on i686) :-(

Comment 15 Mike A. Harris 2004-03-25 19:44:34 UTC
A flaw was discovered in the .8 package, which is fixed in .9, please
try the .9 package and report back.


Comment 16 Alexandre Oliva 2004-03-26 01:17:39 UTC
No change with .9 :-(

Comment 17 Alexandre Oliva 2004-03-26 02:23:22 UTC
It's the environment variable XMODIFIERS=@im=htt that kills xterm and
emacs.  /me wonders how/why it gets set.

Comment 18 Yu Shao 2004-03-26 03:20:44 UTC
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.

Comment 19 Alexandre Oliva 2004-03-26 03:30:06 UTC
service IIim stop then restart X fixes it.  Looks like xinitrc
shouldn't be setting XMODIFIERS for locales such as en_US.UTF-8.

Comment 20 Jens Petersen 2004-03-26 07:24:15 UTC
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.

Comment 21 Jens Petersen 2004-03-26 08:26:12 UTC
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).

Comment 22 Jens Petersen 2004-03-27 13:38:45 UTC
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...

Comment 23 Alexandre Oliva 2004-03-27 17:33:39 UTC
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.

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