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? > I have some [many] warnings like this, > 05/02/02 21:02:20 (CRITICAL): file downloads.c: line 410 (compare_size_func): > assertion `rec[0] && rec[1]' failed > 05/02/02 21:02:20 (CRITICAL): file downloads.c: line 410 (compare_size_func): > assertion `rec[0] && rec[1]' failed > 05/02/02 21:02:20 (CRITICAL): file downloads.c: line 410 (compare_size_func): > assertion `rec[0] && rec[1]' failed I hope you just forgot to run make depend before recompiling. I've never seen those so far. > 05/02/02 18:30:12 (WARNING): UDP datagram (33 bytes) received from bogus IP > 70.59.213.219 > 05/02/02 18:30:13 (WARNING): UDP datagram (405 bytes) received from bogus IP > 70.59.213.219 This should probably be hidden by default. Also this range isn't bogus anymore. It's questionable whether Gtk-Gnutella should really ship with a static list especially considering the frequency of releases. > I also attached to the PID with GDB and there are some random stack > traces at the end of the message. I have gcc 3.4.3 and Linux 2.6.10. > Opps I got another SIGINT while I was writing this (from copy of > stderr). You "got" SIGINT? What do you mean? You pressed Control-C? > opps, another SIGPIPE and now I was demoted and then my window close > worked. GTKG starts to exit. SIGPIPE is quite normal. > 05/02/02 21:34:13 (WARNING): being demoted from Ultrapeer status (for 7200 > secs) > 05/02/02 21:34:36 (WARNING): idtable_destroy: destroying table with 1079 ids > > ** ERROR **: file prop.c: line 542 (prop_get_boolean): assertion failed: (ps > != NULL) > aborting... > And then I get a core dump. Maybe I should when I am messing with > GDB. I think this is just from the ERROR message above? Yes, that's from the assertion failure. However, it seems you haven't compiled it with full debug information. You'll have to use Configure with something like -Doptimize='-g3 -O0' to make sure stacktraces are useful. > 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. > 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)? -- Christian
pgpbCkTzLzgGA.pgp
Description: PGP signature
