[neil s-z org: Patch workaround for Debian Bug#406673]

[Rodrigo Gallardo <rodrigo debian org>]

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 <neil s-z org> -----

Date: Sat, 8 May 2010 07:46:19 -0400
From: Neil Moore <neil s-z org>
To: 406673 bugs debian org
Subject: Bug#406673: Workaround for
X-Spam-Level: 
Reply-To: Neil Moore <neil s-z org>, 406673 bugs debian org
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, neil s-z org, http://s-z.org/neil/



----- End forwarded message -----
----- Forwarded message from Neil Moore <neil s-z org> -----

Date: Sat, 8 May 2010 08:04:07 -0400
From: Neil Moore <neil s-z org>
To: 406673 bugs debian org
Subject: Bug#406673: Workaround
X-Spam-Level: 
Reply-To: Neil Moore <neil s-z org>, 406673 bugs debian org
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, neil s-z org, http://s-z.org/neil/



----- End forwarded message -----

-- 
Rodrigo Gallardo