Bug 869959 - xterm stopped working!
Summary: xterm stopped working!
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xterm
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Miroslav Lichvar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 870653 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-25 08:47 UTC by Nadav Har'El
Modified: 2012-11-26 16:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-26 16:43:24 UTC


Attachments (Terms of Use)
fix which will be in patch #286 (13.00 KB, patch)
2012-10-25 23:51 UTC, Thomas E. Dickey
no flags Details | Diff

Description Nadav Har'El 2012-10-25 08:47:57 UTC
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 08:59:56 UTC
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 09:19:00 UTC
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 09:23:18 UTC
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 09:32:03 UTC
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 09:39:24 UTC
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 09:44:28 UTC
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 09:45:55 UTC
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 09:48:29 UTC
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 09:52:30 UTC
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 09:57:54 UTC
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 09:58:57 UTC
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 10:00:20 UTC
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 10:10:56 UTC
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 10:43:29 UTC
no problem (thanks for the report)

Comment 15 Thomas E. Dickey 2012-10-25 10:50:06 UTC
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 14:11:34 UTC
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 14:33:02 UTC
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 14:46:26 UTC
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 20:38:43 UTC
metacity sets the property.  But the bug is worth fixing.

Comment 20 Thomas E. Dickey 2012-10-25 23:51:21 UTC
Created attachment 633593 [details]
fix which will be in patch #286

Comment 21 Thomas E. Dickey 2012-10-25 23:53:38 UTC
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 07:09:17 UTC
*** Bug 870653 has been marked as a duplicate of this bug. ***

Comment 23 Thomas E. Dickey 2012-10-30 00:28:41 UTC
#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 08:51:52 UTC
Thanks, Thomas. I'll prepare an update shortly.

Comment 25 Fedora Update System 2012-10-30 14:00:55 UTC
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 14:04:05 UTC
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 20:12:55 UTC
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).


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