On 2 Feb 2005, [EMAIL PROTECTED] wrote:
> Bill Pringlemeir wrote:
>> I have opened a filter window with .96 taken some time on the
>> weekend. I update the source last night (via SourceForge CVS), but
>> there were no updated.
>
> You have src/core/sockets.c rev. 1.21, right?
[EMAIL PROTECTED] core]$ ident sockets.c
sockets.c:
$Id: sockets.c,v 1.21 2005/01/28 08:43:22 cbiere Exp $
$Id: sockets.c,v 1.21 2005/01/28 08:43:22 cbiere Exp $
>> I have some [many] warnings like this,
>> 05/02/02 21:02:20 (CRITICAL): file downloads.c: line 410 (compare_size
>> 05/02/02 21:02:20 (CRITICAL): file downloads.c: line 410 (compare_size
>> 05/02/02 21:02:20 (CRITICAL): file downloads.c: line 410 (compare_size
> I hope you just forgot to run make depend before recompiling. I've
> never seen those so far.
I didn't do a make depend. I did a make clean and then a make. I
think that this should be equivalent [except taking more time].
>> What can I do to determine where GTKG is spending its time when
>> this kind of thing happens? How could I help debug this? It only
>> seems to happen every few days, so it is difficult to reproduce.
> Run strace/trace/ktruss/ktrace when this happens to see what kind of
> system calls occur (if any). That could give a hint. When you use
> gdb you can press Control-C and then look at the stacktrace. Then
> continue and try again. Look where it's most of the time. On
> Solaris you also have ptrace (IIRC) that allows you to get real-time
> stacktrace without having to launch a debugger and interrupt the
> process - which has often side-effects.
I thought of this, but I was thinking that I had to launch a program
with these options. I didn't know you could attach to a PID. I will
have to check the man pages to see how to do this. "strace -p PID".
Thanks! I have also setup to compile with your options.
>> 0x4042d440 in g_slist_last () from /usr/lib/libglib-2.0.so.0 (gdb)
>> bt #0 0x4042d440 in g_slist_last () from /usr/lib/libglib-2.0.so.0
>> #1 0x4042cd79 in g_slist_append () from /usr/lib/libglib-2.0.so.0
>> #2 0x08c29548 in ?? () #3 0x08755d08 in ?? () #4 0xbffff2e8 in ??
>> () #5 0x081076a3 in vp_gui_fi_status_changed (fih=148312600) at
>> visual_progress.c:691 #6 0x080a0192 in file_info_update
>> (d=0xc5164b0, from=75133578, to=75134229, status=DL_CHUNK_DONE) at
>> fileinfo.c:3346
>
> Do you have entries in ~/.gtk-gnutella/fileinfo with a huge amount
> of chunks (e.g., 100 and more)?
One file had 140 chunks.
Regards,
Bill Pringlemeir.
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
