Bug 869959

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?

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

If you are willing to compile more xterm versions, bisecting to the first version which has this problem would help a lot. Thanks.

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.

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.

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).

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.

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.

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.

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).

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...

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).

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!

no problem (thanks for the report)

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.

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.

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.

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.

metacity sets the property.  But the bug is worth fixing.

Created attachment 633593 [details]
fix which will be in patch #286

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.

*** Bug 870653 has been marked as a duplicate of this bug. ***

#286 is out now.  (It's a small update since I'm interested in ironing
out problems from the large changes in 279-282).

Thanks, Thomas. I'll prepare an update shortly.

xterm-286-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/xterm-286-1.fc18

xterm-286-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xterm-286-1.fc17

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).