Menu
▾
▴
[Tcl-bugs] [ tktoolkit-Bugs-3117468 ] Malformed %A substition under solaris.
|
From: SourceForge.net <no...@so...> - 2012-04-25 14:42:38
|
Bugs item #3117468, was opened at 2010-11-24 02:14 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3117468&group_id=12997 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 01. Bindings Group: obsolete: 8.5.9 >Status: Pending >Resolution: Works For Me Priority: 9 Private: No Submitted By: Tobias Fendin (fendin) Assigned to: Donal K. Fellows (dkf) Summary: Malformed %A substition under solaris. Initial Comment: %A substitution in bind scripts is broken. For example, character å becomes å5þpNþ(converted to hex: E5 35 FE 70 06 4E FE 01). In Unicode å is denoted by U+00E5. The garbage is different depending on the previously entered character (å is substituted correctly when it is the first character sent to the wish process). This behavior can be seen in Tcl/Tk 8.5.9, but not in 8.5.8. This is similar to 3080953, but this is seen under solaris as well. System information: $ uname -a SunOS simx 5.10 Generic_137138-09 i86pc i386 i86pc Solaris $ locale LANG=en_US.ISO8859-1 LC_CTYPE="en_US.ISO8859-1" LC_NUMERIC="en_US.ISO8859-1" LC_TIME="en_US.ISO8859-1" LC_COLLATE=sv_SE.ISO8859-1 LC_MONETARY="en_US.ISO8859-1" LC_MESSAGES="en_US.ISO8859-1" LC_ALL= ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2012-04-25 07:42 Message: Hmm, I can't correlate those stack traces with the tkBind.c from Tk 8.5.9 as tagged. The line which is supposedly calling abort() is in the middle of a comment! Will not attempt to make further progress against what is looking like an unknown codebase. Please retry with 8.5.11 *with no custom changes* and report any issues. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2011-06-02 10:08 Message: status for 8.5.10 ? ---------------------------------------------------------------------- Comment By: Tobias Fendin (fendin) Date: 2010-11-30 02:47 Message: I've uploaded a stack trace from a core file which was produced by a abort in ExpandPercents. The abort was called the second time ExpandPercents was called with a %A. I also printed the result of the typecast (from XEvent to TkKeyEvent) which would have taken place in tkUnixKey.c/TkpGetString. Do not hesitate to ask for more debugging information. ;) ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-11-25 14:50 Message: Well, I'd love to know what's crapping out at the moment. :-) I'm trying to work out whether the problem is due to there being random extra crap in the event, or some extra data that something needs which we're not allowed to zero out. The former case is easy to fix, the latter isn't (shadow boxing with an unknown piece of software isn't my favourite game). ---------------------------------------------------------------------- Comment By: Tobias Fendin (fendin) Date: 2010-11-25 13:24 Message: Donal: From what point do you want the stack trace? From the abort() in my experimental code previously posted or at some other point? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-11-25 08:32 Message: Jan: It smells like that to me too. The issue is that there's something in there, and maybe something other than Tk is doing the same sorts of dirty tricks that we're up to. It would be nice if we could see a stack trace in the crash case(s); I can't test for myself (I'm on OSX). ---------------------------------------------------------------------- Comment By: Tobias Fendin (fendin) Date: 2010-11-25 04:15 Message: I tested to let ExpandPercents only call TkpGetString once and store the result. It seems to work and it should not interfere with anything else. If you want a clean patch I can create one. ---------------------------------------------------------------------- Comment By: Tobias Fendin (fendin) Date: 2010-11-25 03:26 Message: If this snippet is placed before the while loop in ExpandPercents the insertions works as expected: { TkKeyEvent* kePtr3 = (TkKeyEvent*)eventPtr; if (kePtr3->charValuePtr != NULL && kePtr3->charValuePtr > (char*)4096) { ckfree(kePtr3->charValuePtr); kePtr3->charValuePtr = NULL; kePtr3->charValueLen = 0; } } The code clears the pointer that TkpGetString uses for caching its return value. If the check '> (char*)4096' is removed wish will seg fault, indicating that some other function is using that memory. Wouldn't it be better if ExpandPercents only called TkpGetString once and stored its return value in a separate buffer? That way TkpGetString would not have to worry about interacting with XIM more than once per event. ---------------------------------------------------------------------- Comment By: Jan Nijtmans (nijtmans) Date: 2010-11-25 01:49 Message: This smells like (exceprt from ChangeLog): 2010-01-02 Donal K. Fellows <dk...@us...> * unix/tkUnixEvent.c (TransferXEventsToTcl): [Bug 1924761]: Use the new cache mechanism to force the extraction of the string of a key event from XIM at the right time rather than after queueing when it can be quashed by a race condition centered on the limited amount of state in some XIM implementations. * unix/tkUnixKey.c (TkpGetString): [Bug 1373712]: Cache the value that * generic/tkInt.h (TkKeyEvent): will be substituted via %A so * generic/tkEvent.c (CleanUpTkEvent): that we do not need to make it * doc/HandleEvent.3 (ARGUMENTS): fresh each time, which causes * doc/QWinEvent.3 (ARGUMENTS): trouble with some input * macosx/tkMacOSXKeyEvent.c (InitKeyEvent): methods. Also includes the * win/tkWinX.c (GenerateXEvent): factoring out of some code and update of documentation to describe the slightly increased constraints on how Tk_HandleEvent can be used. 2010-01-01 Donal K. Fellows <dk...@us...> * unix/tkUnixEvent.c (TransferXEventsToTcl): [Bug 1924761]: Move the * generic/tkEvent.c (Tk_HandleEvent): passing of key events to XFilterEvent to the low level point where all other events are handled, where it should have been all along. This makes more input methods work, stops [event generate] from interfering with input methods, and allows the simplification of tkEvent.c by removing half of InvokeInputMethods and allowing the rest - which was not full input method handling - to be rolled back into Tk_HandleEvent. Introduces a small potential bug when a focus change and input method handling are too close together in the Tk event queue, but that should be less deadly to usability than the previous problems where input methods could fail completely or reorder key presses... ---------------------------------------------------------------------- Comment By: Tobias Fendin (fendin) Date: 2010-11-25 01:20 Message: TkpGetString() returns it's cached value at it's first invocation for the event. Which seems incorrect since it can't have allocated memory (kePtr->charValuePtr) for this event yet. TkpGetString typecasts its XEvent *eventPtr to a TkKeyEvent, which seems odd to since those structs are not equal. I can't figure out if it's intended or not, I'm not too familiar with the code. Where are kePtr->charValuePtr and charValueLen supposed to be freed and cleared? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2010-11-24 02:50 Message: The problem with the %A substitution is that it couples to the XIM machinery (yuck!) and must be fetched at most once for any event. What exactly is going wrong... I don't know yet. Just warning that this is a tricky area. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=3117468&group_id=12997 |