search

eserte / perl-tk

the perl module Tk
https://metacpan.org/release/Tk
Other
44 stars 31 forks source link

Fixed XmuClientWindow, was killing Perl with BadWindow #10

Open mcast opened 9 years ago

mcast commented 9 years ago

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.

mcast commented 9 years ago

In internal discussion, the question arose "from where is this called?". tkEvent.c

mcast commented 9 years ago

I noticed some evidence (shaky, due to insufficient logging of atom numbers) that the message causing this is a _NET_WM_PING; and that our ignoring this by trapping the BadWindow is then causing the tk app to be effectively "xkill"ed.

Why would our tk windows get _NET_WM_PING (on Ubuntu Lucid Gnome desktops) when we have only WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW or on the MainWindow, WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_SAVE_YOURSELF

Therefore, the fix may not be as simple as just masking the error with a handler..?

mcast commented 9 years ago

We would like to get this merged so we can deploy a release version which doesn't crash this way. Do I need to make any changes?

mcast commented 9 years ago

Ed (a co-worker) brought up the suspicious

pTk/mTk/xlib/X11/X.h:#define InputFocus 1L /* destination window in SendEvent */

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 Window 0x1 was passed to Tk without translation to the actual windowid. Surely X should do that? But maybe not.