Bug 467525
| Summary: | unkillable blank xterm | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Alex Chiang <achiang> | ||||
| Component: | xterm | Assignee: | Miroslav Lichvar <mlichvar> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 10 | CC: | mlichvar, pertusus, rpacheco, sandmann | ||||
| Target Milestone: | --- | Keywords: | Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2009-12-18 06:35:46 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
This is definitely not a metacity problem. Reassigning to xterm. 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. 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? 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? 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. 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)
That looks like a problem with connection to XIM. Which input method do you use? 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. 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? 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. 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 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 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. |
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.