Re: [GNUnet-developers] gnunet-gtk crashes

[Tom Barnes-Lawrence]

Whee, a bit more on this again.
(For reference, I've already started using 0.6.1 by now)

On Thu, Dec 18, 2003 at 04:15:04AM +0000, Tom Barnes-Lawrence wrote:
<snip>
>  Sorry, I realise I expressed myself a bit badly there:
> by "as soon as I tried to enter a search", I strictly meant "immediately
> after pressing enter, having typed the keyword". Specifically, the
> keyword was one that had previously yielded results with gnunet-search,
> so it would already have results in the db.
> 
>  In the past (many months back), I tried to figure out exactly what
> circumstances these segfaults occurred: often it seemed like it would
> be when the first search results came in, other times it seemed like
> the number of searches already running within gnunet-gtk made a
> difference, etc etc.
> 
>  In the end, I realised there didn't seem to be such an easy to spot
> pattern to it. Still, I might see if I can get Valgrind to eventually
> produce more valuable results than it did the first time.


 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.

Now, I tried it again under gdb, and then it stopped, gdb reported the
segfault, and said, suprisingly,
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2051 (LWP 808)]
0x40224201 in _Xutf8GenericDrawString () from /usr/X11R6/lib/libX11.so.6
(gdb) 

..which in fact, it did a couple of nights back when I tried it then.
This time, I remembered to do a backtrace, as I'm a bit more awake.

(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) 

Now, how do you like that? It has actual function names and stuff this
time. Perhaps I've updated some packages since last time *shrug*.

So anyways, I don't know, but my impression is: gnunet is cranking out
results faster than (something else) can deal with it. Either it's too
fast for gtk and that's throwing out bad args to the lower-level X
functions (but Christian, you said you've got the same GTK version
as me), or perhaps my old version of X (4.1.0) is buggy and just
throws up on large strings.
Or some other thing. Anyways, I wouldn't have a clue how to fix it,
or even if it would be possible. But it'd be nice if somebody else
were at least able to reproduce this or work out the *why* of it.

 Tomble