Patrik Fimml un jour écrivit:
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.
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?
They didn't appeared until I pressed enter for the password. They appeared
on a separate line, probably just after the password line, but I am not
100% sure for the exact line.
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.
That would makes sense, since on a x86 computer the caracters are
replaced by bigs round dots in the gui and that there is no output in the
text console.
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).
Since my default shell is tcsh, the syntax for me is:
setenv DEB_BUILD_OPTIONS 'nostrip noopt'
I am a little surprised that it did not strip the symboles, but just
ignored the rest of the line without complaining (or I missed it).
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
That gives me this, with 0xff and 0xfc being ÿ and ü:
{0xff, 0xfc, 0x0, 0xd8, 0x10, 0x25, 0x99, 0x10, 0x10, 0x39}
I also give you a little more. I guess that sl->Width=-1 means that
the length is unknown?
(gdb) p /x *sl
$13 = {_vptr.NLine = 0x10120b18, Text = 0x10390bd0, NBytes = 0x2, Color =
0xffffff, Width = 0xffffffff,
Timestamp = 0x4978ab46}
(gdb) p /x *fl
$15 = {<NLine> = {_vptr.NLine = 0xbfd23950, Text = 0x100a4064, NBytes =
0x101da800, Color = 0x28, Width = 0xbfd23980,
Timestamp = 0x101daa18}, Src = 0xfb3b810, Off = 0x0, X = 0xbfd23970,
Y = 0x100a4124, H = 0x101da808, valid = 0xbf,
stamp = {0xd2, 0x39, 0x80, 0x10, 0x1c, 0xc, 0x28, 0x10, 0x1d, 0xa8,
0x0, 0xf}}
And here, I give you the full backtrace before entering the function.
328 if (!g_utf8_validate(tp+j,k-j,NULL)) continue;
(gdb) bt full
#0 NText::formatLine (this=0x101da800, i=40) at ntext.cc:328
j = 0
k = 2
l = -1076741840
w = -1076741856
color = 16777215
fit = false
sl = (NLine *) 0x10395c68
fl = (FLine *) 0xbfd23930
tp = 0x10390bd0 "ÿü"
elw = 705
#1 0x100a3678 in NText::append (this=0x101da800, text=0xbfd23f34 "ÿü",
len=2, color=16777215) at ntext.cc:262
i = -1076741760
nl = (NLine *) 0x10395c68
p = 0x0
#2 0x100f60d4 in Text::append (this=0x101da800, msg=0xbfd23f34 "ÿü",
color=16777215, imp=IM_NORMAL) at text.cc:132
No locals.
#3 0x100f3728 in TextSet::append (this=0x101d9ca8, msg=0xbfd23f34 "ÿü",
color=16777215, imp=IM_NORMAL) at text.cc:181
ti = {_M_node = 0x101df748}
#4 0x100c4f34 in FicsProtocol::doOutput (this=0x10259880, msg=0xbfd23f34
"ÿü", channel=-1, personal=false,
msgcolor=16777215) at proto_fics.cc:824
No locals.
#5 0x100c767c in FicsProtocol::parser2 (this=0x10259880, T=0xbfd23f34
"ÿü") at proto_fics.cc:346
No locals.
#6 0x100c79fc in FicsProtocol::parser1 (this=0x10259880, T=0xbfd23f34
"ÿü") at proto_fics.cc:312
pstring =
"¿Ò>0\000\000\000\002¿Ò<p\017Ï\031пÒ<p\020\0301°\020\035¹ð\020\035µè\017³¸\020\020\035º\220¿Ò;\020\017ª8ô\017úë
\020\035º\220¿Ò;0\017Ã\001\204\000\001f\000\000\000\000\000\017Ã\001°¿Ò;x\017úÐL\000\000\000\000¿Ò;P\017¾&L\000\000\020\000\020\0301°¿Ò;x\017Ã\001°\017úë
\020\0301°¿Ò;p\017Ã\021\200\0206\020P\000\000V\000\020\030é\200\020\035¹ð\017úë
\020\0301°¿Ò; \017Ã2\220\020\0301°\020\035¹ð¿Ò; ¿Ò>0\017\214\200\\¿Ò>0¿Ò;
¿Ò>0\017û&p\017Ã1À"...
Here, I wondered if the caracters I previously saw in Etch were not
"úë" instead of "ÿü", but maybe they always have been "ÿü".
#7 0x100c7a54 in FicsProtocol::receiveString (this=0x10259880,
netstring=0xbfd23f34 "ÿü") at proto_fics.cc:247
No locals.
#8 0x10088020 in MainWindow::readAvailable (this=0x10187470, handle=7) at
mainwindow.cc:1687
net = (class NetConnection *) 0x1035e718
line = "ÿü", '\0' <repeats 2045 times>
gotinput = 1
loopc = 0
#9 0x1008ee30 in netconn_read_notify (data=0x1035e8a0, source=7,
cond=GDK_INPUT_READ) at network.cc:133
me = (NetConnection *) 0x1035e8a0
#10 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
closure = <value optimized out>
gdk_cond = GDK_INPUT_READ
#11 0x0f7b2e68 in g_io_unix_dispatch (source=0x102418f8,
callback=0xfaa34a0 <gdk_io_invoke>, user_data=0x101c0c28)
---Type <return> to continue, or q <return> to quit---
at /build/buildd/glib2.0-2.16.6/glib/giounix.c:162
buffer_condition = <value optimized out>
#12 0x0f76c72c in IA__g_main_context_dispatch (context=0x10186330) at
/build/buildd/glib2.0-2.16.6/glib/gmain.c:2012
No locals.
#13 0x0f770ec8 in g_main_context_iterate (context=0x10186330, block=1,
dispatch=1, self=<value optimized out>)
at /build/buildd/glib2.0-2.16.6/glib/gmain.c:2645
max_priority = 2147483647
timeout = 89
some_ready = 1
nfds = 2
allocated_nfds = <value optimized out>
fds = (GPollFD *) 0x10240b30
__PRETTY_FUNCTION__ = "g_main_context_iterate"
#14 0x0f771604 in IA__g_main_loop_run (loop=0x1028c6f8) at
/build/buildd/glib2.0-2.16.6/glib/gmain.c:2853
self = (GThread *) 0x101d2178
__PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#15 0x0fce9bc4 in IA__gtk_main () at
/build/buildd/gtk+2.0-2.12.11/gtk/gtkmain.c:1163
tmp_list = (GList *) 0xbfd24940
functions = (GList *) 0x0
init = (GtkInitFunction *) 0x1010c3c0
loop = (GMainLoop *) 0x1028c6f8
#16 0x1007fa84 in main (argc=1, argv=0xbfd24c14) at main.cc:108
zomb = {_M_node = 0x0}
i = 1
z = (class MainWindow *) 0x10187470
dgtport = 0x0
I remarked the caracters "úë" and wondered if they were the caracters I
saw before on the console.
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.
I have to go now, but I guess I will have to do It unless the code we
are supposed to receive are documented somewere (at least, it is not
ducumented in the code). Maybe we will get a surprise and it will be
something else than "úë" or "ÿü".
By the way, I noticed that the compiler warned that eboard was linked
with a number of apparently unnecessary libraries like libpango. For
Lenny, it is best to keep it like it is now, but it would be a good idea
to look at it for Lenny+1.
Simon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
