Bug 467525 - unkillable blank xterm
unkillable blank xterm
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xterm (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-17 19:30 EDT by Alex Chiang
Modified: 2009-12-18 01:35 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:35:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
screenshot of zombie xterm (595.64 KB, image/png)
2008-10-17 19:30 EDT, Alex Chiang
no flags Details

  None (edit)
Description Alex Chiang 2008-10-17 19:30:08 EDT
Created attachment 320729 [details]
screenshot of zombie xterm

Description of problem:
Once in a while, I lose the contents of whatever is displayed inside of a plain old xterm, and then you cannot close the window when clicking on the close button.

When moving the mouse pointer into the zombie window, the pointer disappears. Moving the pointer back out into the rest of the desktop, the pointer reappears.

Other windows remain responsive, and will close if you click on the close button.

The only way to make the xterm go away is to kill it from the shell.

Version-Release number of selected component (if applicable):
Version    : 2.24.0
Release    : 2.fc10

How reproducible:
random, perhaps 5% of the time

Steps to Reproduce:
1. unknown. :(
  
Actual results:
xterm becomes blank and unresponsive

Expected results:
working xterm?

Additional info:
I'm attaching a screenshot of what I'm talking about. There were no other programs running when I took the shot.

Notice in the 2nd xterm, you can see 2 xterm processes and 2 bash processes.

Issuing a 'kill 3443' made the zombie xterm on the left go away.

Maybe this is not a metacity problem, but I figured this would be a good starting point.
Comment 1 Søren Sandmann Pedersen 2008-10-23 15:21:01 EDT
This is definitely not a metacity problem. Reassigning to xterm.
Comment 2 Patrice Dumas 2008-10-23 19:35:07 EDT
I have never ever seen that on fluxbox, although I use xterms quite intensively. But I guess that a specific setup induces that bug, otherwisethere would have been much more reports.
Comment 3 Miroslav Lichvar 2008-10-24 04:22:45 EDT
Any chance you are using xinerama and xfs? If yes, it could be a duplicate of bug #134930.

Can you please try to get a backtrace next time when xterm is hung?
Comment 4 Alex Chiang 2008-10-24 11:09:26 EDT
Definitely no xinerama and not even using compiz either. And I'm not using xfs.

I will try and get a backtrace next time. You want sysrq-t, right?
Comment 5 Miroslav Lichvar 2008-10-24 13:18:34 EDT
I mean gdb backtrace with xterm-debuginfo package installed.

gdb /usr/bin/xterm pid (where pid is the pid of the hung xterm)

and command "bt" should print the backtrace.
Comment 6 Alex Chiang 2008-10-28 01:44:21 EDT
Here is a backtrace.

0x00110416 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 expat.i386 libICE.i386 libSM.i386 libXau.i386 libXaw.i386 libXcursor.i386 libXdmcp.i386 libXext.i386 libXfixes.i386 libXmu.i386 libXpm.i386 libutempter.i386 ncurses.i386
(gdb) bt
#0  0x00110416 in __kernel_vsyscall ()
#1  0x00bc135d in ___newselect_nocancel () from /lib/libc.so.6
#2  0x00dd5295 in _xcb_conn_wait (c=<value optimized out>, cond=Could not find the frame base for "_xcb_conn_wait".
) at xcb_conn.c:340
#3  0x00dd693f in xcb_wait_for_event (c=<value optimized out>) at xcb_in.c:413
#4  0x00186911 in wait_or_poll_for_event (dpy=<value optimized out>, wait=<value optimized out>) at xcb_io.c:100
#5  0x00186c80 in process_responses (dpy=<value optimized out>, wait_for_first_event=<value optimized out>, 
    current_error=<value optimized out>, current_request=<value optimized out>) at xcb_io.c:115
#6  0x00187447 in _XReadEvents (dpy=<value optimized out>) at xcb_io.c:212
#7  0x0016531b in XIfEvent (dpy=<value optimized out>, event=<value optimized out>, 
    predicate=<value optimized out>, arg=<value optimized out>) at IfEvent.c:70
#8  0x001b43da in _XimXRead (im=<value optimized out>, recv_buf=<value optimized out>, 
    buf_len=<value optimized out>, ret_len=<value optimized out>) at imTrX.c:448
#9  0x001b34d4 in _XimReadData (im=<value optimized out>, len=<value optimized out>, buf=<value optimized out>, 
    buf_size=<value optimized out>) at imTransR.c:154
#10 0x001b3897 in _XimRead (im=<value optimized out>, len=Could not find the frame base for "_XimRead".
) at imTransR.c:231
#11 0x001a0c2c in _XimProtoSetICValues (xic=<value optimized out>, arg=<value optimized out>) at imDefIc.c:759
#12 0x0018d0c2 in XSetICValues (ic=<value optimized out>) at ICWrap.c:339
#13 0x0805d7f5 in PreeditPosition () at ./charproc.c:3386
#14 in_put () at ./charproc.c:3273
#15 doinput () at ./charproc.c:3363
#16 VTparse (xw=0x9a76798) at ./charproc.c:2934
#17 0x0805dd7a in VTRun () at ./charproc.c:4883
#18 0x08069036 in main (argc=8, argv=0xd760) at ./main.c:2400
(gdb)
Comment 7 Miroslav Lichvar 2008-10-29 12:16:00 EDT
That looks like a problem with connection to XIM. Which input method do you use?
Comment 8 Alex Chiang 2008-10-29 12:20:01 EDT
How do I tell?

I never selected an input method during install. I'm using plain old American English for all my language settings and I'm not doing anything weird like dvorak.

The one thing I did do was remap my caps lock key as an additional control.

If you want to tell me how to find out what input method I'm using, I'll be happy to update the bz with the info.
Comment 9 Miroslav Lichvar 2008-10-29 12:42:46 EDT
Not really sure, but I found this page:

http://fedoraproject.org/wiki/Features/IMDesktopIntegration 

It mentions an im-chooser utility, does it show anything interesting?
Comment 10 Alex Chiang 2008-10-29 12:59:33 EDT
I can connect and disconnect from an Input Method.

SCIM is selected as my input method.

In SCIM, I have selected English/Keyboard.

I occasionally attempt to turn SCIM and the im-chooser off (because I really don't need them).

Next time I get this weird xterm hang, I'll take note of whether I'm connected or not connected to SCIM.
Comment 11 Bug Zapper 2008-11-25 22:58:24 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 13 Bug Zapper 2009-11-18 03:35:39 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 14 Bug Zapper 2009-12-18 01:35:46 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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