Gnome, Xemacs, and BadWindow's.

[George Hartzell]

George Hartzell writes:
 > 
 > I'm moving my IBM T42p from 5.3BETA4 to 6.0 STABLE
 > 
 > I've built all the xorg, gnome2, and xemacs stuff from ports
 > portsnap'ed a couple of days ago w/ BATCH=1.
 > 
 > I'm running a GENERIC kernel that was build from today's STABLE
 > sources.
 > 
 > I've created a new user w/ the default .files, using tcsh, and no
 > emacs/xemacs configuration files, so it's unlikely to be anything in
 > my personal configuration (?).
 > 
 > The X server is running w/out any configuration file.
 > 
 > Whenever I type a bit of text into xemacs and "kill" it (e.g. move to
 > the beginning of the line hit control-k), I get a pair of messages in
 > the xterm window from which I started xemacs:
 > 
 >   X Error of failed request:  BadWindow (invalid Window parameter)
 >     Major opcode of failed request:  18 (X_ChangeProperty)
 >     Resource id in failed request:  0xe006b8
 >     Serial number of failed request:  20223
 >     Current serial number in output stream:  20225
 >   X Error of failed request:  BadWindow (invalid Window parameter)
 >     Major opcode of failed request:  25 (X_SendEvent)
 >     Resource id in failed request:  0xe006b8
 >     Serial number of failed request:  20224
 >     Current serial number in output stream:  20225
 > 
 > It only happens when nautilus is running.
 > 
 > xlsclient -la tells me that nautilus has a window who's id is close
 > to the resource id of the failed requests, but I don't know how those
 > id's are generated:
 > 
 >   Window 0xe00001:
 >     Machine:  satchel.alerce.com
 >     Name:  File Manager
 >     Icon Name:  File Manager
 >     Command:  nautilus
 >     Instance/Class:  nautilus/Nautilus
 > 
 > 'Sometimes' (I can't consistently repeat it), stopping nautilus,
 > cutting something in xemacs, then starting nautilus will generate the
 > pair of messages.
 > 
 > I tried to get some feedback a while back about a similar problem that
 > also involved ssh, here's a pointer to the start of that thread:
 > 
 >   http://lists.freebsd.org/pipermail/freebsd-gnome/2005-June/011636.html
 > 
 > I never really resolved it then, just stopped running nautilus (sadly
 > it seems to be responsible for setting the background...).
 > 
 > I get occasional mail from folks who see my earlier post, so I don't
 > think I'm the only person seeing this.
 > 
 > Anyone have any thoughts?
 > 
 > I'd appreciate any leads, hints, pointers, me-too's, works-for-me's,
 > etc.... 

I posted a description of this problem to the xemacs community and
received the following post from "Stephen J. Turnbull"
<stephen at xemacs.org>: 

  It's possible that it's an XEmacs bug, but the last time I tried to
  debug this I put a trace on the window creation function and those
  are definitely not XEmacs's windows.  We may have misimplemented the
  protocol (see below), but the folks who did that work were pretty
  wizardly.
  
  Caveat: I don't understand the following, I'm just repeating what
  somebody else diagnosed.
  
  Apparently some applications misuse the X selection, by setting the
  owner to a window that they later destroy without disowning the
  selection.  The X selection (or maybe it's the clipboard) protocol
  requires some communication with the former owner when this is done,
  but that window no longer exists so you get the bad resource message.
  GNOME applications are apparently especially prone to this behavior.
  
Gnome applications are all a twisty maze of libraries and dependencies
to me.  Can someone suggest where I might start looking to see if it's
actually nautilus that's creating the windows with which xemacs is
trying to communicate?

Thanks,

g.