Hide Forgot
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?
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).