Bug 869959

Summary: xterm stopped working!
Product: [Fedora] Fedora Reporter: Nadav Har'El <nyh>
Component: xtermAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 17CC: dickey, jpirko, mlichvar, pertusus
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-26 11:43:24 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
fix which will be in patch #286 none

Description Nadav Har'El 2012-10-25 04:47:57 EDT
Description of problem:
xterm stopped working on upgrade to xterm-284-1.fc17.x86_64

Version-Release number of selected component (if applicable):
xterm-284-1.fc17.x86_64

How reproducible:

When running xterm (or uxterm, from the same package), I get:

$ xterm
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Resource id in failed request:  0xe0000b
  Serial number of failed request:  131
  Current serial number in output stream:  131

I don't know if this matters, but I'm running on the ctwm window manager, not the "standard" GNOME environment. Needless to say the previous xterm package did not have this problem.

Please also note that upstream has a newer version (284) - maybe they fixed this bug?
Comment 1 Miroslav Lichvar 2012-10-25 04:59:56 EDT
CCing the upstream maintainer. The changelog for 285 doesn't seem to have an entry related to this problem.

Do you have any resources set for xterm?
Comment 2 Nadav Har'El 2012-10-25 05:19:00 EDT
I just compiled 285 from the upstream and it still has this bug, so I'm not trying to debug it and will let you know how it goes.
I do have a bunch of resources for xterm, and have had them for nearly 20 years (!) - listed below. However, I tried removing them, and it didn't help.

XTerm*VT100.Translations: #override\n\
 Meta<Key>S: secure()\n\
 Meta<Key>U: scroll-back(1,line)\n\
 Meta<Key>D: scroll-forw(1,line)\n\
 Meta<Key>Next: scroll-forw(1,page)\n\
 Meta<Key>Prior: scroll-back(1,page)\n\
 Meta<Key>B: set-scrollbar(toggle)\n\
 Alt Shift <Btn4Down>:     string(0x1b) string("[5~") \n\
 Alt Shift <Btn5Down>:     string(0x1b) string("[6~")  \n\
 Alt Ctrl  <Btn4Down>:     string(0x1b) string("OA")   \n\
 Alt Ctrl  <Btn5Down>:     string(0x1b) string("OB")   \n\
 Alt       <Btn4Down>:     string(0x1b) string("OA") string(0x1b) string("OA") string(0x1b) string("OA") string(0x1b) string("OA") string(0x1b) string("OA") \n\
 Alt       <Btn5Down>:     string(0x1b) string("OB") string(0x1b) string("OB") string(0x1b) string("OB") string(0x1b) string("OB") string(0x1b) string("OB") \n\
 Shift     <Btn4Down>:     scroll-back(1,page)         \n\
 Shift     <Btn5Down>:     scroll-forw(1,page)         \n\
 Ctrl      <Btn4Down>:     scroll-back(1,line)         \n\
 Ctrl      <Btn5Down>:     scroll-forw(1,line)         \n\
           <Btn4Down>:     scroll-back(5,line)         \n\
           <Btn5Down>:     scroll-forw(5,line)
XTerm*VT100.saveLines: 256
XTerm*VT100*background: yellow
!XTerm*VT100*background: lightYellow
XTerm*VT100*foreground: black
XTerm*VT100.reverseWrap: true
XTerm*VT100.scrollBar: true
XTerm*VT100.titeInhibit: true
XTerm*VT100*cursorColor: black
XTerm*VT100*backarrowKey: true
XTerm*VT100*deleteIsDEL: true
XTerm*VT100*ttyModes: intr^? erase^H


XTerm*VT100.font:       heb8x13
! I need this font:
!XTerm*VT100.boldFont: heb8x13B
XTerm*VT100.boldFont: 8x13bold
XTerm*VT100.colorBDMode: off
XTerm*VT100.colorULMode: off

! nice, thin, fonts in the menus
XTerm*SimpleMenu*font: -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-iso8859-*
XTerm*SimpleMenu*menuLabel.font: -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-*
! hebrew/latin1 fonts in font menu
XTerm*fontdefault*Label:                תירבע
XTerm*fontMenu*fontdefault*font:        heb8x13
XTerm*font1*Label:      Latin1
XTerm*font1:            8x13
Comment 3 Miroslav Lichvar 2012-10-25 05:23:18 EDT
If you are willing to compile more xterm versions, bisecting to the first version which has this problem would help a lot. Thanks.
Comment 4 Nadav Har'El 2012-10-25 05:32:03 EDT
Ok, I compiled xterm with tracing, and the problem is in:

getWindowManagerName
getProperty _NET_SUPPORTING_WM_CHECK(WINDOW)
... result ok
getProperty _NET_WM_NAME(UTF8_STRING)

Apparently xterm thinks my window manager supports this "_NET" thing because I have:
$ xprop -root _NET_SUPPORTING_WM_CHECK
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x80000b

And yet there is no such window. This causes the bug.
And all this to get the window manager name, which is completely unnecessary anyway.
I'm continuing to debug this.
Comment 5 Thomas E. Dickey 2012-10-25 05:39:24 EDT
which window manager is that?  (I did make a quick check on each
platform using the desktop defaults).  The window manager name is
needed if available for determining which support EMWH features...

At the moment I'm updating my fedora18alpha machine to see more.
Comment 6 Nadav Har'El 2012-10-25 05:44:28 EDT
it's "ctwm", an old (but still supported, and still my favorite...) twm-based window manager.

I think there's an even more basic problem: getWindowManagerName() assumes that if it finds a window id in _NET_SUPPORTING_WM_CHECK, then that window exists. But what if it doesn't? What if the window manager died? Or non-conformant like apparently ctwm is (but I didn't check)? Why does xterm need to exit?

Can the window id be checked for validity before being passed to getProperty() in getWindowManagerName() causing xterm to die? Sadly my xlib skills are rusty, so I don't remember how to do this (check a window id without causing a fatal xlib error).
Comment 7 Thomas E. Dickey 2012-10-25 05:45:55 EDT
I see (ctwm in the initial report).  I had tested ctwm with Debian,
but not with Fedora.  Will look closer, to see how to reproduce the
problem.
Comment 8 Thomas E. Dickey 2012-10-25 05:48:29 EDT
The way to handle errors like this is to (temporarily) install an
error-handler which does something harmless (like print to stderr).
xterm does that for some special case in initialization.
Comment 9 Thomas E. Dickey 2012-10-25 05:52:30 EDT
The feature being checked is in getWindowManagerName in charproc.c
As a quick workaround, you could stub that function, making it
return
    strdup("ctwm")
so that the caller will get usable (and harmless) data.
Comment 10 Nadav Har'El 2012-10-25 05:57:54 EDT
I'm using ctwm-3.8a (it's not a fedora package I compiled it myself).
It's not the latest ctwm release, so I'll try now a newer one hoping they fixed the _NET_SUPPORTING_WM_CHECK stuff.

But in any case, I think you shouldn't rely on the window existing (because the window manager might have died or changed since that setting).
Comment 11 Thomas E. Dickey 2012-10-25 05:58:57 EDT
A quick check with Debian 6 shows it (still) working there.
It's easy to switch window managers with Debian using kdm
(gdm is a different matter), so I've done most of my window
manager testing there.  I'll put together a fix today...
Comment 12 Thomas E. Dickey 2012-10-25 06:00:20 EDT
sure - I should check for errors, but will overlook some cases
which "always" work, until someone points it out :-(
But I think that I can fix this (couple of hours this evening).
Comment 13 Nadav Har'El 2012-10-25 06:10:56 EDT
Thanks. It seems it still doesn't work on ctwm-3.8.1. 

Interestingly, xterm *does* work on the first minute of starting ctwm. Then, a couple of minutes later it stops working. Perhaps the window dies... I'll report this to the ctwm people.

If in any case xterm could be more forgiving to this error, it would be great. Thanks for looking into this!
Comment 14 Thomas E. Dickey 2012-10-25 06:43:29 EDT
no problem (thanks for the report)
Comment 15 Thomas E. Dickey 2012-10-25 06:50:06 EDT
By the way, the check is to provide a usable default for the active-icon
feature.  I initially tested with Debian 5 and ctwm 3.7-3.
(perhaps I should make a table of results to show which can be auto-detected,
and which require manual settings)

In my current test, with Debian 6 and ctwm 3.7-3.1+b1,
I see that the active-icon feature can be made to work.
Comment 16 Nadav Har'El 2012-10-25 10:11:34 EDT
Update: the bug is *not* related to ctwm: If I manually remove the property,
$ xprop -root -remove _NET_SUPPORTING_WM_CHECK
then xterm (of course) returns to working.

But the curious thing is that if I restart ctwm, the property does *NOT* return. Apparently, it was never ctwm which put it there to begin with - apparently ctwm only sets (correctly) _WIN_SUPPORTING_WM_CHECK, but doesn't set _NET_SUPPORTING_WM_CHECK. I also checked ctwm's code - it does not set _NET_SUPPORTING_WM_CHECK.

So this leaves me wonder, what in my Fedora 17 is setting this property.
Comment 17 Miroslav Lichvar 2012-10-25 10:33:02 EDT
Do you use gdm? It runs (or used to run) metacity which sets some resources and does not clean it up after itself. This caused problems to openbox too.
Comment 18 Nadav Har'El 2012-10-25 10:46:26 EDT
Yes, I do use GDM (Fedora's default login screen), and see stuff like gdm-binary, gdm-simple-slave, gdm-session-worker still running even now.
Comment 19 Thomas E. Dickey 2012-10-25 16:38:43 EDT
metacity sets the property.  But the bug is worth fixing.
Comment 20 Thomas E. Dickey 2012-10-25 19:51:21 EDT
Created attachment 633593 [details]
fix which will be in patch #286
Comment 21 Thomas E. Dickey 2012-10-25 19:53:38 EDT
At the moment I've only a few minor documentation issues in mind for #286,
and if the patch is okay, will wait a few days for other reports.
Comment 22 Miroslav Lichvar 2012-10-29 03:09:17 EDT
*** Bug 870653 has been marked as a duplicate of this bug. ***
Comment 23 Thomas E. Dickey 2012-10-29 20:28:41 EDT
#286 is out now.  (It's a small update since I'm interested in ironing
out problems from the large changes in 279-282).
Comment 24 Miroslav Lichvar 2012-10-30 04:51:52 EDT
Thanks, Thomas. I'll prepare an update shortly.
Comment 25 Fedora Update System 2012-10-30 10:00:55 EDT
xterm-286-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xterm-286-1.fc18
Comment 26 Fedora Update System 2012-10-30 10:04:05 EDT
xterm-286-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xterm-286-1.fc17
Comment 27 Fedora Update System 2012-10-30 16:12:55 EDT
Package xterm-286-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xterm-286-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17236/xterm-286-1.fc18
then log in and leave karma (feedback).