Menu

#2 Various important Bugs to look at

v1.0_(example)
open
nobody
None
1
2014-07-23
2013-03-07
me me
No
  • Fix the program's associations with Java so it works with Java 7 and later. Problem is known to affect Windows and it seems some Linux systems.

  • Remove the program's auto-deletion of the gnutella.net connection cache file if the gnutella file is one month or more old.

  • There seems to be an issue on Windows when 64-bit Java is installed last. Seems the program only runs in 32-bit presently. Result is a startup error message and a preferences folder created at first level of user documents with a dot in front of the name. (LuckyWire creates a similar dot folder at same location.)

  • A list of other bugs posted at GF here http://www.gnutellaforums.com/getting-started-using-limewire/97321-limewire-pirate-edition-18.html#post364493

One of note is:

  • Java memory management. I remember seeing a post at the Java site about dealing with this. Something about increasing the memory drop off (garbage collection) from 256 to 512 or something like that.
    Just google Java.lang.OutOfMemoryError: PermGen space
    One suggestion I saw was:
  • Find the cause of Memory Leak or if there is any memory leak.
  • Increase size of PermGen Space by using JVM param -XX:MaxPermSize and -XX:PermSize.
    Try -XX:MaxPermSize=256m and if it persists, try -XX:MaxPermSize=512m
    Or -XX:MaxPermSize=512m and -XX:PermSize=512m
    It can be a permanent fix if the root cause is not classloader leakage, just too many classes/static data.

In most of JVM, default PermSize is around 64MB which runs out of memory if there are too many classes or huge number of Strings in the project.

Garbage collection is the mechanism of automatically freeing up the memory contained by the objects that are no longer referenced by the program. Memory leaks mean some items are not removed during this process.

-vm < path to the right JRE directory >/<name of="" javaw="" executable=""></name>

For some odd reason the program has less RAM and VM maximum set compared to the v4.

Other important notes:

  • increase ratio of queue to upload slots.

  • upload bandwidth either periodically leaks or … ? I've seen it show 70 KB/s with nobody downloading at all. This kills uploads as they struggle to get any bandwidth at all.

  • Greedy clients classification for those only downloading individual files. Usually because the upload technology has gone buggy for an hour or several. ie: they are unable to restart their downloads, sometimes stopped in middle of downloading. I would consider this a considerable major bug. Program restarts do not always fix it. Probably rebooting computer would. (Memory release issue also?) ie: upload message: Unable to upload: upload limit reached!
    Despite upload slots pushed up to 50 for a few hours. I feel really sorry for the persons downloading who are caught in this scenario.

Discussion


Log in to post a comment.