Re: [TCLCORE] XEvent crash

[Donal K. F. <don...@ma...>]

On 05/02/2013 16:07, Brian Griffin wrote:
> The basic problem is that the charValuePtr is not null, so an attempt
> is made to free it.  The XEvent was created as a pure XEvent, not a
> TkKeyEvent.  The fields accessed by the cleanup code where never set.
> The fundamental problem, as I see it, is that there is an implied
> contract for an XEvent (outside of Tk) that only the fields related
> the xevent.type are to be accessed, and any other parts of the union
> will be ignored.  That implied contract is being ignored here.

The problem is that there is *also* an implied contract with respect to
key events that Xutf8LookupString/XmbLookupString are only called once
for any particular event (which is essential for input method handling
to be even remotely sane). The only way to guarantee that given the way
we need to handle '%A' substitutions in multiple binding sets is to
cache the result (which is what the charValuePtr field is doing). Yes,
this isn't great and I agonized quite a bit before doing it (this is all
Bug 1373712) but I don't see any better solution, given that the correct
lifespan of the string matches the event's lifespan and that could be
quite long if someone reenters the event loop. :-(

> I've worked around the problem by zeroing out the XEvent struct
> before setting it up.  But, am I wrong in my assumption?  Is there
> something I'm missing when using Tk_QueueWindowEvent()?

You've got the correct workaround/fix.

Donal.