Randomly I (and two other co-workers using RH9 on different machines) get: xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 25 (X_SendEvent) Resource id in failed request: 0x120914f Serial number of failed request: 20897 Current serial number in output stream: 20898 Xlib: unexpected async reply (sequence 0x51a2)! xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x120914f Serial number of failed request: 20896 Current serial number in output stream: 20898 And xemacs hangs. I have no idea how to debug this further... any suggestions?
*** Bug 90388 has been marked as a duplicate of this bug. ***
I have only had one other report of this problem, and I unfortunately don't know how to reproduce it. If you have a way of reproducing it easily please let me know.
I ran xemacs with -syncronous in gdb and got this stack trace. Xlib: unexpected async reply (sequence 0x3a04f)! xemacs: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x10666b3 Serial number of failed request: 237646 Current serial number in output stream: 237647 Program received signal SIGINT, Interrupt. [Switching to Thread 1082870848 (LWP 4960)] 0xffffe002 in ?? () (gdb) bt #0 0xffffe002 in ?? () #1 0x4044da07 in _XRead () from /usr/X11R6/lib/libX11.so.6 #2 0x4044e54d in _XReply () from /usr/X11R6/lib/libX11.so.6 #3 0x40449975 in XSync () from /usr/X11R6/lib/libX11.so.6 #4 0x40449a37 in _XSyncFunction () from /usr/X11R6/lib/libX11.so.6 #5 0x4042d3e5 in XChangeProperty () from /usr/X11R6/lib/libX11.so.6 #6 0x081b0f84 in console_type_create_redisplay_x () #7 0x081b12d8 in x_handle_selection_request () #8 0x080f9320 in event_stream_handle_magic_event () #9 0x080fd5b6 in Fdispatch_event () #10 0x0809ba6b in Fcommand_loop_1 () #11 0x080b4df3 in condition_case_1 () #12 0x0809b4ea in Freally_early_error_handler () #13 0x0809b51b in Freally_early_error_handler () #14 0x080b4a49 in internal_catch () #15 0x0809b677 in initial_command_loop () #16 0x080b1349 in xemacs_21_4_12_i386_redhat_linux () #17 0x080b1df2 in main () #18 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 (gdb) Doesn't look too handy, is there anything I can do to help?
Are you using more than one XEmacs frame at the same time by the way?
Very likely, I normally have around 6 frames open.
I also experience this bug. I don't usually have multiple frames open when it happens. Every time it has happened has been when I switched workspaces and came back. For example, xemacs is working fine, I switch to another workspace and do something else a moment, I come back, and the xemacs window won't redraw, and I get the X error messages listed above.
I have since starting seeing it too with a single frame. With 21.4.13 too. Wonder if building --with-gtk would help?
Just got hit again mid-typing, so it is not caused by workspace switching.
In the next build, I'm going to try moving to another toolkit, ie Xaw3d Athena instead of Motif, to see if that should help.
Could you please try with xemacs-21.4.13-3 in rawhide? It hasn't hanged for me yet afair.
I've installed it, and will report back...
Damn, I managed to install xemacs-21.4.13-4 + Canna + db4 and I get this message: xemacs: relocation error: xemacs: symbol sys_siglist, version GLIBC_2.3.3 not defined in file libc.so.6 with link time reference It looks like the package doesn't declare its glibc dependancy tightly enough.
Hmmm, sounds like an rpm bug. If so please it separately under rpm. Thanks.:) If you want to try the latest xemacs on RHL9, then you'll need to rebuild the srpm yourself. (Also note that the sumo packages are now in xemacs-sumo.)
So far so good!
*** Bug 102761 has been marked as a duplicate of this bug. ***
Unfortunately, Severn/Rawhide does not resolve the issue. If you leave emacs running for a good strech (I often leave mine up overnight and resume work in the morning), the problem as I reported in Bug 102761 shows up again. The cursor starts getting stuck again, and it begins to not work properly when using things like the desktop switcher. Additionally, the problem seems to readily appear when any window is on top of Xemacs, covering a portion of the window (say a shell window or a chat window). I am currently using mouse-over focus. Switching to mouse-click focus eliminates the problem of the cursor not working right with the desktop switcher--but the cursor icon can still be confused by some movement back and forth over top of the xemacs window border. Despite the icon being confused, all mouse cursor clicks seem to work properly. Switching back to mouse-focus does not appear to cause the problem to resume--but I have not tested it several hours out. It may resume given enough time. I would suggest that there is something wrong with how Xemacs works with focus and the metacity window manager. Perhaps the way Xemacs works with focus breaks something in metacity's mouse-focus code? Looks like you will need to reopen this issue :-(
The thread http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=86vfnghscv.fsf%40pc-nrp.dev.mon.bbc.co.uk&rnum=4&prev=/groups%3Fq%3Dmozilla%2Bxemacs%2B%2BX%2BError%2Bof%2Bfailed%2Brequest:%2B%2BBadWindow%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26selm%3D86vfnghscv.fsf%2540pc-nrp.dev.mon.bbc.co.uk%26rnum%3D4 has something to say about this -- it maybe a font conflict due to mozilla/java putting an extra path into the font path. I've heard rumours that this is fixed with Mozilla 1.6, but haven't confirmed this. David