[Bug: 21.4.12] xemacs: X Error of failed request: BadWindow(invalid Window parameter)

[Glynn Clements]

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
received.

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
overlooking.

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:

X_SendEvent
  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
X_ChangeProperty
  Resource id in failed request:  0x2800120

X_SendEvent
  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).

Or xscope/xmon/etc.

-- 
Glynn Clements <glynn at gclements.plus.com>