Tcl Source Code

File Added - 274716: pitsana.tk

Logged In: YES 
user_id=75003
Originator: NO

Testing this on Linux (SuSe 9), confirmed.

Notes:
* Adding a \t to the puts seems to prevent the error, but also seems to cause an infinite loop.
* Printing information in a separate puts has no influence on either, allowing us to monitor the various variables.
* Adding \t does cause infinite loop, with $i reaching '2.0' and then staying there forever.
* Without the \t the reported error occurs when $i is 1.63. This seems to coincide with the a-umlaut character (The char after 'pitki').

... It seems that the infinite loop is just a bad end condition
... xi = 1.0, 'xi display lineend' comes back as 1.0 as well, and that value is never reached by the loop (starts at 1.82, drops to 1.1, then increments to either 1.63 for error, or 2.0 without).

* I managed to reduce the string, use 'M a-umlaut u', i.e. just 3 chars, and that is good enough. Having the a-umlaut as first char, or only two chars, i.e. without u makes the problem go away.

I am suspecting that it is less in puts, and more something in the text widget creating a bad internal string.

Logged In: NO 

With the current Tcl/Tk HEAD as of today:

There may be 2 bugs here.  1 seems to be that the TkTextIndex (both of them for the [.t get]) ->linePtr are the same for every iteration, and the other is that the byteIndex advances when it's supposed to be a display line advancement.

I added this to just before the TextGetText() call in the TEXT_GET path:
printf("index1Ptr->linePtr %p index1Ptr->byteIndex %d\n", (void *)index1Ptr->linePtr, index1Ptr->byteIndex);
printf("index2Ptr->linePtr %p index2Ptr->byteIndex %d\n", (void *)index2Ptr->linePtr, index2Ptr->byteIndex); 

...
Tcl_Obj *get = TextGetText(textPtr, index1Ptr, index2Ptr, visible);

Then I added this bit of code:  
 {
 char *p;
 int len;
 p = Tcl_GetStringFromObj(get, &len);
 printf("length %d\n%s\n", len, p);
 printf("p[0] = %x\n", p[0] & 0xff);
 } 

 index1Ptr->linePtr 0x820aca0 index1Ptr->byteIndex 63
 index2Ptr->linePtr 0x820aca0 index2Ptr->byteIndex 63

 index1Ptr->linePtr 0x820aca0 index1Ptr->byteIndex 64
 index2Ptr->linePtr 0x820aca0 index2Ptr->byteIndex 65 
 length 1 

 p[0] = c3 

That's the only point that it has a byteIndex > 0, and that's when it produces the error in the puts path.  From what I've read 0xc3 is not a valid UTF-8 character.  0xC3,0x83 on the other hand might be.  I'm not sure whether the bug is in GetIndex of the text widget (which returns the invalid byteIndex) or TextGetText -- they both may have bugs.

This is a Tk text widget bug: display lineend can land inside a multi-byte character, so [.t get] returns the lone first byte of "ä" and [puts] fails. Moved to the Tk tracker as 18f35ed566, with a smaller reproducer. The script attached here no longer fails with the current branches, since Tk 7d8d10e4a9 lays out an unmapped text widget at its requested size, but the bug itself remains.