Patrik Fimml un jour écrivit:
>>
More exactly, it start as usual, but when connecting to a chess server,
it hangs and consume 100% CPU once the user have entered a user name.
[...]
If I press 'return here, the screen draw an additionnal '>' on the next
line, and the window hangs (it cannot be closed except by pressing CTRL-C
twice in a console or by killing it).
Are you using a custom login script (~/.eboard/scripts/autofics.pl) that
does weird stuff, maybe? If yes, please try without the script.
No. Also, before sending the bug report, I uninstalled and purged the
package, rename the ~/.eboard/ folder and reinstalled eboard and tested it
again just to make sure it was not something like that.
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?
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.
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.
(gdb) bt
#0 0x0f7ab194 in IA__g_utf8_validate (str=0x102b4048 "ÿû", max_len=2,
end=0x0)
at /build/buildd/glib2.0-2.16.6/glib/gutf8.c:1754
#1 0x1005a4c4 in NText::formatLine (this=0x1016ca10, i=34) at ntext.cc:328
#2 0x1005c4b0 in NText::append (this=0x1016ca10, text=0xbff95f48 "ÿû",
len=2, color=16777215) at ntext.cc:262
#3 0x1008d15c in Text::append (this=0x1016ca10, msg=0xbff95f48 "ÿû",
color=16777215, imp=IM_NORMAL) at text.cc:132
#4 0x1008bc64 in TextSet::append (this=<value optimized out>,
msg=0xbff95f48 "ÿû", color=16777215, imp=IM_NORMAL)
at text.cc:181
#5 0x1006c78c in FicsProtocol::doOutput (this=<value optimized out>,
msg=0xbff95f48 "ÿû", channel=<value optimized out>,
personal=<value optimized out>, msgcolor=<value optimized out>) at
proto_fics.cc:824
#6 0x10073aa0 in FicsProtocol::parser1 (this=0x1025b3c0, T=0xbff95f48
"ÿû") at proto_fics.cc:312
#7 0x100493b8 in MainWindow::readAvailable (this=<value optimized out>,
handle=<value optimized out>) at mainwindow.cc:1694
#8 0x1004fce8 in netconn_read_notify (data=<value optimized out>,
source=<value optimized out>, cond=<value optimized out>)
at network.cc:133
#9 0x0faa351c in gdk_io_invoke (source=<value optimized out>,
condition=<value optimized out>, data=<value optimized out>)
at /build/buildd/gtk+2.0-2.12.11/gdk/gdkevents.c:986
#10 0x0f7b2e68 in g_io_unix_dispatch (source=0x102b0df8,
callback=0xfaa34a0 <gdk_io_invoke>, user_data=0x101c88f8)
at /build/buildd/glib2.0-2.16.6/glib/giounix.c:162
#11 0x0f76c72c in IA__g_main_context_dispatch (context=0x1010d330) at
/build/buildd/glib2.0-2.16.6/glib/gmain.c:2012
#12 0x0f770ec8 in g_main_context_iterate (context=0x1010d330, block=1,
dispatch=1, self=<value optimized out>)
at /build/buildd/glib2.0-2.16.6/glib/gmain.c:2645
#13 0x0f771604 in IA__g_main_loop_run (loop=0x10213440) at
/build/buildd/glib2.0-2.16.6/glib/gmain.c:2853
#14 0x0fce9bc4 in IA__gtk_main () at
/build/buildd/gtk+2.0-2.12.11/gtk/gtkmain.c:1163
#15 0x10045d44 in main (argc=1, argv=0xbff96be4) at main.cc:108
Can anybody else reproduce this on PPC?
I used to have a Sparc computer. That would actually have been very
handy to test my theory about endianness and confirm the bug, but
unfortunately I don't have it anymore.
I am also a little surprised that nobody reported it before.
Simon Valiquette
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
