Fixed XmuClientWindow, was killing Perl with BadWindow #10
Conversation
to fix a rare but persistent BadWindow crash
seen on (Lenny, Lucid) Gnome desktop
often after closing another application
event sequence:
ClientMessage: serial=42280 send_event=1 win=0x1 mtype=atom#275 fmt=32 data=0x120 0x2d044 0x1 0x0 0x0
XmuClientWindow(win 0x1)
ClientWin.c:65: XGetWindowProperty for atom#311 'WM_STATE' of 0x1 on :0.0 [Last=42282, next=42283]
atom#275 is WM_PROTOCOLS
without the patch, ClientWin.c:65 will provoke an error e.g.
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 20 (X_GetProperty)
Resource id in failed request: 0x1
Serial number of failed request: 1586296
Current serial number in output stream: 1586296
…ndow-BadWindow * fix/XmuClientWindow-BadWindow.old: wrap XmuClientWindow's XGetWindowProperty in Tk_CreateErrorHandler
|
In internal discussion, the question arose "from where is this called?". tkEvent.c |
|
I noticed some evidence (shaky, due to insufficient logging of atom numbers) that the message causing this is a Why would our tk windows get Therefore, the fix may not be as simple as just masking the error with a handler..? |
|
We would like to get this merged so we can deploy a release version which doesn't crash this way. |
|
Ed (a co-worker) brought up the suspicious after reading Xlib Reference Manual (vol 2). The circumstances of crashes do suggest an input focus change caused by one application closing and some Tk widget regaining focus. We don't understand why the event with |
I finally tracked down the cause of a BadWindow that was unceremoniously killing our application.
I still don't know what is sending the ClientMessage(WM_PROTOCOL) to us or how to provoke that,
but it gives a windowid=0x1 and the would crash the app until d2446dd.
I haven't attempted to test that XmuClientWindow still works, but I have seen ClientMessages go past
which would otherwise have crashed.