[Bug: 21.4.12] xemacs: X Error of failed request: BadWindow(invalid Window parameter)
glynn at gclements.plus.com
Thu Nov 18 17:58:26 EST 2004
Darryl Okahata wrote:
> > I've spent some time looking into similar errors in the past; I made
> > some comments in:
> > http://list-archive.xemacs.org/xemacs-beta/200309/msg00056.html
> Here, you say:
> The window ID is taken from the SelectionRequest event, and
> doesn't look remotely valid; X window IDs tend to look like:
> 0x00?000??, where the ?s are non-zero. So, at a glance, it looks
> like the problem may result from a bogus SelectionRequest event.
> That's what I was wondering, because of the recursive calls to
> execute_internal_event(). Recursive event processing makes me queasy.
> I can't help but muse:
> * As you say, one possibility is a synthetic SelectionRequest event with
> a bad window parameter (or some app is spewing bogus events).
> Perhaps, something inside XEmacs is generating it and putting it into
> the event queue.
> * With recursive event handlers, could something be occurring
> out-of-order? Maybe the handling is not really supposed to be
> recursive (with selections?)?
Maybe not; although others have reported similar problems, and the
backtrace doesn't normally indicate recursion.
Unfortunately, there's a lot of complexity because the selection code
trying to perform the selection "dialogue" synchronously, i.e.
changing local properties then waiting for the requestor to
acknowledge it. This requires processing events; "user" events are
enqueued for later processing, but the rest are processed as they are
I would have thought it better to wait for a specific event and
enqueue everything else, but there may well be factors which I'm
More generally, whenever I've tried to implement synchronous functions
on top of an event-driven interface (i.e. with a local "main loop"),
I've always ended up being bitten repeatedly until I gave up and
redesigned the code to use callbacks.
> * Tony's problem (one of them, at least) seems to be occurring when he
> hits ^G. Perhaps an event structure (possibly synthetic) is being
> corrupted or not being properly initialized because of the interrupt?
Possibly, although Tony's XIDs are reasonably plausible:
Resource id in failed request: 0x25096cc
Resource id in failed request: 0x25096cb
Resource id in failed request: 0x2509663
Resource id in failed request: 0x25096e6
Resource id in failed request: 0x25096d0
Resource id in failed request: 0x25096e8
Resource id in failed request: 0x2800120
Resource id in failed request: 0x240a4ca
IIRC, the top 12 bits of an XID are the client ID and the bottom 20
bits are the per-client resource ID. 0x96e8 is relatively high for the
latter, but not totally out of the question.
> * Maybe someone (Tony?) could add some debugging printf()'s to display
> the window IDs of received SelectionRequest events? This might help
> to narrow down the problem (bogus events vs corrupted events).
Glynn Clements <glynn at gclements.plus.com>
More information about the XEmacs-Beta