fork bomb, instability in 2.8.5, 2.8.6

[AlHaz]

I have a problem where 2.8.5 and .6 - sometimes immediately upon execution but sometimes upon becoming an ultrapeer - spawn hundreds (literally) of java forks and become unusable. This happens with the sun 1.4.0 vm and with the ibm 1.3.1 vm

with 2.8.6, it's worse because it starts popping up error dialogs faster than i can close them. I eventually go to a different console to killall -KILL java. I am unable to copy/paste the contents of the error dialog because xwindows becomes unusable due to constantly shifting focus.

Also in 2.8.6 there is a tendency for the ui thread to stop functioning (no screen update) when i try to look at the connections tab, though it's clear limewire is still running in some sense because it's using plenty of cpu cycles and bandwidth. I've waited as long as 20 minutes for it to come back before killing it.

I don't have any of these problems in 2.7.13, but I've spoken to a friend who has the same problems with 2.8 versions. I believe this is probably the same issue as another poster mentioned, having to do with java out of memory errors. The number of searches and number of downloads don't have anything to do with this. "ps ax | grep java | wc -l" returning 241 does.

It doesn't matter, but my linux is debian/woody running on a two-processor intel system with 640 megs of ram, and i am launching limewire with an unmodified runLime.sh script, and installed using the tarball.

[trap_jaw]

That's not a bug, it's not exactly a feature either but it's compatible to bloody MacOS.

LimeWire needs two threads per connection, that makes up to 162 as an ultrapeer, plus at least one thread per download plus GUI thread, plus one thread per upload, plus, plus, plus....

The developers are trying hard to reduce the number of threads needed. - If they could use java's non blocking io, they could use a lot less threads but unfortunately MacOS doesn't support it (like so many things that could boost LimeWire's performance).

[AlHaz]

Fine, but 2.7 doesn't become unusable and 2.8 does.

I've got plenty of ram. If limewire wants to use a lot, whatever. As long as it keeps working. Currently, recent versions, it doesn't.

[trap_jaw]

Well, it run's on my system (SuSE 7.3 Athlon TB 800Mhz, 256mb ram), using Sun's jre 1.4. No matter if I'm running as an ultrapeer or not and sharing ~6000 files.

There might be problems while LimeWire is hashing your files. I don't know anything else what could be causing your problem (except for maybe more than a hundred downloads at the same time).

Yeah, I have a problem like that too, ps -aux | grep LimeWire | wc -l reports 214 limewires running, it works, but it seems a little, excessive. Anyhoo, I just came to find out if it was leaking threads or something, but if that is the normal mode of operation, so be it. I guess it isn't hurting anything.

[trap_jaw]

There was a thread problem in 2.6 or 2.5 but it has been fixed. Every now and then I'm running LimeWire in debug mode and so far the thread management seems okay in 2.8.X.

Originally posted by trap_jaw
There was a thread problem in 2.6 or 2.5 but it has been fixed. Every now and then I'm running LimeWire in debug mode and so far the thread management seems okay in 2.8.X.

Can't be too fixed, I'm running 2.8.6 and it was hanging around two hundred fifteen to two hundred thirty threads. It threw some kind of exhaustion error once, but seemed to survive. It didn't seem to be a problem, but it didn't seem quite right either.

[trap_jaw]

215-230 threads is normal for LimeWire (v2.8.6-). You need a gui thread, one thread per upload/download, two threads per regular gnutella connection, a garbage collector thread, and so on.

I was encountering the same problem as the orriginal poster when upgrading to 2.8 ... occasionally Limewire would crash HARD, an error dialog with an exception would pop up, but the whole app would look up before there was any time to look at the exception.

When someone in this thread mentioned that it's not unusal for Limewire to use several hundred threads/processes I figured out what theproblem is...

Dependig on what Linux kernel you are using, and how your system is configured there may be a hard limit on the total number of processes allowed per user, or for the whole system.

Aparently, in Limwire versions <2.8, Limewire rarely needs more then 256 processes ... i say this, becuase i almost never had this problem with Limewire 2.7, even though my shell was conifugred to only allow me to use 256 processes.

depending on whhch shell you use, you should look into either the "limit" or "ulimit" commands. You should also search for "PAM" which is an administration tool that allows root to set hard limits on users regardless of what they set in their shell.

HOWEVER, on top of all of this, is the possibility of an evern more dominating limit ... aparently in teh Linux 2.2.x kernels, there is an absolute hard limit 512 processes for the whole system. (this can be changed at compile time, but the fact remains -- there is a hard limit which can't be changed without recompiling the kernel.)