>>> If you need any more information or want me to try a patch, just ask me.
>>
>> Please try to get a backtrace with debugging symbols after the freeze
>> occurs and you hit CTRL-C.
>
> Okay, I found out that it was looping inside NText::formatLine exactly
> between the following lines in the file ntext.cc:
>
> 320 while(k-j > 0) {
> 321 fit = false;
> 322
> 323 // try full-fit for for unwrapped of last chunk of wrapping
> 324
> 325 if (j==0 && sl->Width >= 0) {
> 326 w = sl->Width;
> 327 } else {
> 328 if (!g_utf8_validate(tp+j,k-j,NULL)) continue;
>
> Obviously, "g_utf8_validate()" always returns false so the execution
> flow always move back to the start of the "while" loop.
>
> Is it just me that is very tired, or will it always test exactly the
> same string?Yes, it will. > The only sane explanation that came to my mind is that on x86, unless > there is something wrong, the data are almost always valid Unicode on the > first try (which seems reasonnable). > > It looks like a cut&paste error because just after, there is a "for" > loop with almost exaclty the same code, except that the code makes more > sense and don't always test the same data. > > It would also means that on big endian systems, there is maybe another > bug somewhere that made this bug show up. Yeah. The code is weird enough, but we shouldn't even get that far. > Here the backtrace in case you would still want to see it. On Etch, > there was also 2 stranges (but innocent looking) caracters appearing just > after login. I can't remember for sure if it was "ÿû" exactly, but I do > remember that it was some accented letters. Do you know where they appeared? After your login name, or after the "password:" prompt, or anywhere inbetween? My guess is that the characters used to make a terminal not display its input (i.e. if you were entering your password over a telnet FICS session) are upsetting eboard. Actually, the guide I linked has got it wrong, you need to set DEB_BUILD_OPTS="nostrip noopt", separated by a space, not a comma. Please re-compile eboard without optimizations for further debugging, and get a detailed backtrace (bt full). Please dump the raw byte contents of the trouble-causing buffer. Assuming you break in g_utf8_validate again, you could do: (gdb) p /x *...@10 Besides, a dump of the network traffic would probably be helpful. With netcat, you could do $ nc -l -p 5000 -c 'nc -o eboard-tcp-log freechess.org 5000' and let eboard connect to localhost:5000 to get a hex dump in eboard-tcp-log. Kind regards, Patrik
signature.asc
Description: Digital signature
