Re: [GNUnet-developers] gnunet-gtk crashes

[Tim Müller]

On Saturday 27 December 2003 02:54, Tom Barnes-Lawrence wrote:

>  So anyhow: One of the things that usually seemed to nuke gnunet-gtk was
> entering a search that produced a huge block of results at once.
> For example, entering a keyword of "video" was pretty reliable at this.
>
> Trying that when running gnunet-gtk under valgrind didn't seem to
> make it crash, but trying again with gnunet-gtk just running *normally*
> still does, I tried it a few times tonight. It's presumably so reliable
> because gnunetd stores the old search results in the db so they come
> out all at once.

did valgrind show any other problems though? (accessing freed memory, 
accessing uninitialised memory, buffer-off-by-one etc.)

> (gdb) ba
> #0  0x40224201 in _Xutf8GenericDrawString () from
> /usr/X11R6/lib/libX11.so.6 #1  0x4022430b in _XmbGenericTextEscapement ()
> from
> /usr/X11R6/lib/libX11.so.6
> #2  0x401df13f in XmbTextEscapement () from /usr/X11R6/lib/libX11.so.6
> #3  0x4015efce in gdk_string_width () from /usr/lib/libgdk-1.2.so.0
> #4  0x400637c8 in gtk_clist_undo_selection () from /usr/lib/libgtk-1.2.so.0
> #5  0x40063dc4 in gtk_clist_undo_selection () from /usr/lib/libgtk-1.2.so.0
> #6  0x40063f2c in gtk_clist_undo_selection () from /usr/lib/libgtk-1.2.so.0
> #7  0x40059322 in gtk_clist_thaw () from /usr/lib/libgtk-1.2.so.0
> #8  0x0804e44b in displayResultGTK (rootNode=0x809e940, model=0x8099a20)
>     at search.c:440
> #9  0x4029e09d in processResult (rootNode=0x809e940, rc=0xbf5ffa84)
>     at searchutil.c:100
> #10 0x4029e206 in filterResult (rootNode=0x809e940, keyIndex=0, keyCount=1,
>     rc=0xbf5ffa84) at searchutil.c:147
> #11 0x4029e567 in receiveResults (sock=0x8099a80, keyCount=1,
>     keywords=0x809e890, messages=0x809e5f0,
>     handler=0x804e064 <displayResultGTK>, handlerArgs=0x8099a20,
>     testTerminate=0x804e48c <testTermination>, ttContext=0x8099a20)
>     at searchutil.c:283
> #12 0x0804e4bf in receiveResults_ (args=0x809e920) at search.c:480
> #13 0x403110ba in pthread_start_thread () from /lib/libpthread.so.0
> #14 0x40311101 in pthread_start_thread_event () from /lib/libpthread.so.0
> (gdb)

#4, #5, and #6 indicate IMHO that the stack got corrupted somehow. Whether 
this happened inside or outside of gtk/X is not quite clear of course, but 
I'd say that it is _highly_ unlikely that you are witnessing a gtk/X bug here 
(which gtk version was that again? 1.2.10?). GtkCList is one of the most 
common-used widgets of gtk+-1.2, and XFree 4.1 was also quite common back 
then when gtk+-1.2 was not completely outdated, and both probably have been 
stress-tested fairly thoroughly in that combination.

So what to do? I suppose it might be helpful to build a copy of gtk that has 
debugging symbols, so that gdb can show the arguments passed to the various 
gtk/gdk functions. Another thing to look out for are threads: I have never 
looked at the gnunet-gtk code in much detail, so I might be completely off 
track here, but gtk per se is not thread-safe. In other words: you cannot 
access gtk widgets from different threads without some precautions 
(gtk_clist_freeze() is not enough for that). The fact that it happens without 
valrgind but not with valgrind is an indication that there might be a 
timing-related thing going on there, so threading stuff is a good candidate 
IMHO.

Another thing to check is whether there are any non-ASCII characters (or 
non-locale characters) in the strings to be displayed. I don't really 
remember how gtk1.2 deals with strings and character encodings etc, so I'm 
just saying this with regard to the _utf8 function somewhere in the backtrace 
(even though that backtrace may only be partly reliable and the upper frames 
might be bogus)

I'll give it a try when I get back at the beginning of January, if you haven't 
sorted it out by then.

Cheers
-Tim