Re: [Gtk-gnutella-users] Resource Limits

[Richard E. <wyl...@us...>]

On Mit, 2002-09-18 at 14:05, pw...@mu... wrote:
> 
> I am kind of a heavy GTK-Gnutella user:
> 
> 	Gnutella Version: 0.90 stable
> 	OS: Red Hat 7.3
> 	System: 1.2Mhz AMD Duron, 256Mb 
> 
> 	Files shared: +/- 12000 (about 100Gb)
> 	Download Queue Size: about 200 files
> 	Active Searches: 10 or so, with a total of 1000 pending hits
> 	Active Filters: about 15
> 	Gnutella net connections: 5
> 	Upload slots: 5
> 
> I occasionally get core dumps.  I have general stability problems like
> the reported number of active uploads is higher in the status bar than
> in the upload screen, and sometimes files from my download queue start
> appearing on my upload screen.  In addition, sometimes I have stability
> problems with other applications (like Mozilla) when I use GTK-Gnutella.
> 
> Am I exceeding some hard coded resource limits in GTK-Gnutella?  Can
> anyone tell me what they are and what the best strategy to avoid
> them is?

When you get a core dump, use gdb to aquire a stack trace and post this
to the -devel list or here.

If the total number of uploads exceeds your set maximum, check if you
have "dynamic slot allocation" enabled on the bandwidth configuration
pane. If you do, you might want to disable it.

Do you maybe share the directory you download files to or keep
incomplete files in? Check this, and especially don't share the
directory you keep your incomplete files in.

If your computer crashes under heavy load, you maybe have deficient
memory chips or something similar. Afaik there are no hard-coded limits
in gtk-gnutella and there are some other people that have similar
metrics like you. The stack traces I mentioned above might be helpful.

There is a "run" script in the gtk-gnutella cvs which you can use to run
gtk-gnutella. It's not perfect, but it will fire up gdb if gtkg dumped
core. Once inside gdb, you can use the "bt" command to dump a trace.
Be sure to keep the core file and the binary that produced it in a safe
place since it might be useful for further diagnosis.

But first of all, make sure that your hardware is not the cause of the
trouble. 

Richard