I received the following proposed patch for Debian bug#406673 "sawfish: error message with java window"
I just realized that a mysterious "beep" that I was hearing every time I move to a workspace running Aladin (a non-debian java application: http://aladin.u-strasbg.fr/java/nph-aladin.pl?frame=downloading) was sawfish-related. In each "beep" I receive the following error message in .xsession-error: Bad argument: #<subr x-atom-name>, 18446744072353249216, 1 I'd be glad if someone in the list could give it a test, I've been kind of busy lately and won't be able to for a while. ----- Forwarded message from Neil Moore <[email protected]> ----- Date: Sat, 8 May 2010 07:46:19 -0400 From: Neil Moore <[email protected]> To: [email protected] Subject: Bug#406673: Workaround for X-Spam-Level: Reply-To: Neil Moore <[email protected]>, [email protected] X-Debian-PR-Message: followup 406673 X-Debian-PR-Package: sawfish X-Debian-PR-Keywords: X-Debian-PR-Source: sawfish X-Spam_bar: -- The following patch works around the problem for me. The real problem is twofold: 1. Java is generating __NET_WM_STATE messages with very large X atom numbers for data[2], that do not correspond to real atoms. I'm not sure if this is legal or not, or what the numbers might mean if it is legal. Normally Sawfish would treat a this would be fine, because if the atom is not found Sawfish's x-atom-name subr evaluates to nil. However: 2. The atom numbers are so large that they do not fit into a rep_INTP. This causes the rep_DECLARE1 in x-atom-name (src/functions.c) to fail and signal the bad-arg error that is the symptom of the problem. The patch below doesn't deal with #2 directly. Instead, it catches the error and, if it is raised, treats atom2 as nil (just as would happen if the number were smaller and did not refer to an atom). This should be fine, as long as there are no real X atoms with numbers that high (0x2000000 and up). I'm not really familiar enough with the C part of sawfish and rep to know how to properly fix the problem. One could have x-atom-name also accept a rep_BIGNUM; however, this would require some work to verify that the argument is in range before passing it to XGetAtomName. --- lisp/sawfish/wm/state/wm-spec.jl.orig 2010-05-08 07:05:58.806028157 -0400 +++ lisp/sawfish/wm/state/wm-spec.jl 2010-05-08 07:06:10.585947672 -0400 @@ -543,7 +543,7 @@ ((eql (aref data 0) _NET_WM_STATE_ADD) 'add) ((eql (aref data 0) _NET_WM_STATE_TOGGLE) 'toggle))) (atom1 (x-atom-name (aref data 1))) - (atom2 (x-atom-name (aref data 2)))) + (atom2 (condition-case () (x-atom-name (aref data 2)) (bad-arg nil)))) (when (or (and (eq atom1 '_NET_WM_STATE_MAXIMIZED_VERT) (eq atom2 '_NET_WM_STATE_MAXIMIZED_HORZ)) (and (eq atom2 '_NET_WM_STATE_MAXIMIZED_VERT) -- Neil Moore, [email protected], http://s-z.org/neil/ ----- End forwarded message ----- ----- Forwarded message from Neil Moore <[email protected]> ----- Date: Sat, 8 May 2010 08:04:07 -0400 From: Neil Moore <[email protected]> To: [email protected] Subject: Bug#406673: Workaround X-Spam-Level: Reply-To: Neil Moore <[email protected]>, [email protected] X-Debian-PR-Message: followup 406673 X-Debian-PR-Package: sawfish X-Debian-PR-Keywords: X-Debian-PR-Source: sawfish X-Spam_bar: -- Apologies for all the typos in the text of the previous message; I was somewhat distracted while writing it up. Most importantly, I wrote "0x2000000", where I meant "0x20000000" (2**29). I'm still not clear on why 0x3fffffff isn't accepted, as that should fit into a 32-bit integer (it will be negative, but still a rep_INTP). -- Neil Moore, [email protected], http://s-z.org/neil/ ----- End forwarded message ----- -- Rodrigo Gallardo
