[plt-scheme] DrScheme/MrEd crash on x86_64

I'm having a repeatable crash with DrScheme on x86_64 (Debian).  Burlen 
Loring reported what looks like the same error in November, in this message:

http://list.cs.brown.edu/pipermail/plt-scheme/2004-November/007217.html

The error message is essentially identical (same X error, same major 
opcode, same value):

X Error of failed request:  BadValue (integer parameter out of range for 
operation)
   Major opcode of failed request:  18 (X_ChangeProperty)
   Value in failed request:  0x40
   Serial number of failed request:  1726
   Current serial number in output stream:  1727

The symptom occurs both with the Debian binary package of DrScheme 209, 
and the CVS exp-tagged 299 from yesterday.

The error occurs when attempting to select text anywhere in DrScheme, or 
even in the MrEd REPL.  Selection of text appears to occur normally, 
whether the shift key or the left mouse button is used, but as soon as 
the shift key or mouse button is released, the error occurs and 
MrEd/DrScheme dies.

I've only tested this on a single system, running Debian amd64/pure64 
unstable (sid), on Linux kernel 2.6.8-10-amd64-k8, with KDE 3.3.2.  I 
can't swear that there's not some problem with the environment, which is 
a new one for me.  However, I don't see this symptom in other apps.

Matthew previously asked for some info about the error (on Tue, 16 Nov 
2004):

 > We've tested MzScheme on x86_64, but not MrEd. I imagine the
 > problem is that one of MrEd's uses of XtVaGetValues passes
 > the address of the wrong kind of integer (where the two kinds
 > happen to have the same size on a 32-bit machine, but not a
 > 64-bit machine).
 >
 > I'll scan the source code for bad calls. Meanwhile, if you
 > have a chance, the result of the following debugging session
 > may help me:
 >
 >   % gdb <pltdir>/bin/mred
 >   (gdb) run -synchronous -mvqM drscheme
 >   ... eventually aborts ...
 >   (gdb) where

This returned "No stack".  However, setting a breakpoint on _XError 
allowed a stack trace to be obtained when the error occurs, which I've 
attached.  It looks pretty generic, though, so the offending code wasn't 
obvious to me.

If I can help with any other debugging, let me know.

Anton

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: plt64-xerror.txt
URL: <http://lists.racket-lang.org/users/archive/attachments/20050409/63015ad3/attachment.txt>