Date: Thu, 1 Dec 2005 10:25:04 -0800 From: George Hartzell <hartzell@kestrel.alerce.com> To: hartzell@alerce.com Cc: freebsd-gnome@freebsd.org Subject: Re: Gnome, Xemacs, and BadWindow's. Message-ID: <17295.16384.576201.274549@satchel.alerce.com> In-Reply-To: <17292.64754.774767.955262@satchel.alerce.com> References: <17292.64754.774767.955262@satchel.alerce.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17295.16384.576201.274549>