On 17 Feb 2005, [EMAIL PROTECTED] wrote:
> I've tried to reproduce the crash with passive searches and GTK2 but
> had no success at all. GTKG ran perfectly fine for 9 hrs in UP mode.
> However, after opening 20 passive searches the GUI became so
> horribly unresponsive that I shut it down forcefully.
I just re-ran my "test". I let it run while I am at work. It seems
like I am a servent for most of the day. "netstat -tn | wc" is often
returning 100+ numbers when I peek via ssh. I have four passive
sessions running with auto-downloads in two of them. It doesn't seem
to matter which one I clear. I think that the same thing happens in
active searches [but I am not too sure about that]. Closing a search
is fine. Clearing the results always seems to cause the problem.
unref_record in search.c always seems to be in the trace. So I set a
break point there and then did the clear. When it hit, the break
point I ran a back trace. As soon as I continued, I got a SEGV. I
had done this before and had to continue several times. Perhaps there
is a small probability of it happening for each record cleared?
Anyways does this first trace look corrupt? If so, what higher level
function might I break on first?
(gdb) b unref_record
Breakpoint 1 at 0x815ffd5: file search.c, line 122.
(gdb) c
Continuing.
Breakpoint 1, unref_record (model=0x0, path=0xbfffe670, iter=0xbfffe6f0,
data=0x89b9350) at search.c:122
(gdb) bt
#0 unref_record (model=0x0, path=0xbfffe670, iter=0xbfffe6f0, data=0x89b9350)
at search.c:122
#1 0x401be48b in gtk_tree_model_rows_reordered ()
from /usr/lib/libgtk-x11-2.0.so.0
#2 0x089b9350 in ?? ()
#3 0x08ed9be0 in ?? ()
#4 0xbfffe6f0 in ?? ()
#5 0x0835aae0 in ?? ()
#6 0x089b9350 in ?? ()
#7 0x08317768 in ?? ()
#8 0xbfffe6f0 in ?? ()
#9 0x401bc8bb in gtk_tree_model_get_iter () from /usr/lib/libgtk-x11-2.0.so.0
#10 0x089b9350 in ?? ()
#11 0xbfffe6f0 in ?? ()
#12 0x08ed9be0 in ?? ()
#13 0x401bb8cb in gtk_tree_path_new_first () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x08ed9be0 in ?? ()
(gdb) c
Continuing.
[WJP: why didn't that trace back to main?]
Program received signal SIGSEGV, Segmentation fault.
0x08137e61 in search_gui_hash_func (rc=0xae80e08) at search_common.c:363
(gdb) bt
#0 0x08137e61 in search_gui_hash_func (rc=0xae80e08) at search_common.c:363
#1 0x404102a4 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0
#2 0x6cdc6044 in ?? ()
#3 0x08ed9be0 in ?? ()
#4 0x08ed9be0 in ?? ()
#5 0x4028ae40 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#6 0x08ed9be0 in ?? ()
#7 0x08ed9be0 in ?? ()
#8 0xbfffe678 in ?? ()
#9 0x0816011d in unref_record (model=0x0, path=0xc45c700, iter=0x8,
data=0x45c70000) at search.c:135
Previous frame inner to this frame (corrupt stack?)
(gdb)
> Thus, Purify would come in quite handy as I don't really have an
> idea where to start looking at all.
I guess I should look at getting that and installing it. I have
dmalloc installed, as well as the stack smasher and gprof. The
problems happened before all that stuff. Could it also be the
Mandrake GTK2? I didn't recompile GTK from source.
thx again,
Bill Pringlemeir.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
