Re: [GNUnet-developers] gnunet-gtk crashes

[Igor Wronsky]

On Sat, 27 Dec 2003, 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.

Doesn't happen here. It has always handled e.g. image/jpeg
and thats a huge set of junk.

> ..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*.

And actually the crash happens inside gnunet(gtk(gdk(x11))) if
you like my lispy expression. I don't see a good indication
that it would have much to do with gnunet-gtk. Maybe it has.
Maybe not. We could have an unterminated string somewhere
but I suspect that in that case we should have segfaulted
way before getting to x11 level. A possible cause of action
would be to contact gtk/gdk/x11 authors/gurus and ask if
they have seen anything like it, and if yes, what could cause it.

I admit I'm too lazy to start looking at gtk/gdk/x11 code
to understand an error I can't reproduce.

> 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

If gtk can't handle tight loops of freeze();append();thaw();
thats its internal problem. I think thats unlikely though.


Igor