Tcl Source Code

View Ticket
Login
Ticket UUID: 1943546
Title: Strangely failing [puts]
Type: Bug Version: obsolete: 8.5.2
Submitter: kaitzschu Created on: 2008-04-16 01:09:28
Subsystem: 24. Channel Commands Assigned To: andreas_kupries
Priority: 5 Medium Severity:
Status: Open Last Modified: 2008-08-16 09:24:48
Resolution: None Closed By:
    Closed on:
Description:
Confirmed on Fedora Core 7, OpenSuse 10.2, Windows 2000 and XP.

When running attached script it emits quite a few blankish lines and after that spits out

error writing "stdout": invalid argument

without any apparent reason. And stdout is still writable. In comp.lang.tcl Twylite figured out that [$t get ...] returns not-quite-empty value 0xC3 and considered "some sort of encoding problem" being there.

Drawing widget or changing length of sample text changes snippets behavior, selected category is mostly a guess.

Expected behavior: not giving me errors, naturally .)
User Comments: [email protected] added on 2008-08-16 09:24:48:
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.

andreas_kupries added on 2008-04-17 00:22:50:
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.

kaitzschu added on 2008-04-16 08:09:28:

File Added - 274716: pitsana.tk

Attachments: