bugmldonkey, a multi-networks file-sharing client - Bugs: bug #7222, Memory leak in mldonkey still...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #7222: Memory leak in mldonkey still exists and is quite bad.

Submitter:  Joseph R. Kiniry <kiniry>
Submitted:  Tue 13 Jan 2004 01:10:01 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Memory leak Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2-5-21 Release: 
Operating System:  Linux Binaries Origin:  CVS / Self compiled
CPU type:  None

Jump to the original submission

Tue 24 Aug 2004 10:01:40 AM UTC, comment #17: 

After running a build of the latest CVS snapshot for several days, transferring a dozen or so large file (i.e., my typical usage), the mlnet client seems to use a reasonable, linear amount of memory.  Thus, based upon my testsing, mlnet no longer seems to have the serious memory leak I reported. 

Initial memory use was between 10 and 20MB, and maximal memory use is around 50MB:

 1928 kiniry    10   0 47136  45m 2624 S  0.3  4.5  22:40.86 mlnet

Joseph R. Kiniry <kiniry>
Sun 22 Aug 2004 12:14:32 PM UTC, comment #16: 

I was out of town on-and-off for a few weeks.  Sorry for the delay.  I have built the latest CVS snapshot that you indicated and it is running now.  I will have data for you in the next day or two.

Joseph R. Kiniry <kiniry>
Sat 21 Aug 2004 11:37:11 AM UTC, comment #15: 

You can find a tarball of current CVS here:
download.berlios.de/pub/mldonkey/spiralvoice/cvs
What about the bug? Still there?

spiralvoice <spiralvoice>
Group administrator
Tue 10 Aug 2004 08:42:40 PM UTC, comment #14: 

May I simply build the CVS HEAD (or HEAD at a specific date) rather than download a tarball to build?

I'm trying this now.

Joseph R. Kiniry <kiniry>
Tue 10 Aug 2004 06:42:57 PM UTC, comment #13: 

Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://savannah.nongnu.org/download/mldonkey/

spiralvoice <spiralvoice>
Group administrator
Sun 23 May 2004 09:00:55 PM UTC, comment #12: 

Have you tried the memory leak fix patch on savannah? It fixed the problem for me.

Anonymous
Thu 13 May 2004 09:41:27 AM UTC, comment #11: 

As mentioned in the last response, I am now running 2.5.21.  It has been running now for 11 1/2 hours. 

Unfortunately, if anything, the memory leak is now worse.  Here is the report from top:
  PID USER     PR NI VIRT RES  SHR  S %CPU %MEM  TIME+ COMMAND
 5536 kiniry   11  0 396m 396m 5344 S  1.0 39.3 11:31:21 mlnet
Please let me know if you'd like any additional data on this process.

Joseph R. Kiniry <kiniry>
Tue 11 May 2004 09:53:01 AM UTC, comment #10: 

I updated to release-2-5-21 and am now testing it.  Oddly, when I press the "Help+" button in the HTTP-based interface it reports: "MLNet 2.5-18".  After running for about 10m mlnet is using 26.5MiB of memory.  I'll let it run for a few days and report back the change in memory use at that time.

Joseph R. Kiniry <kiniry>
Sat 08 May 2004 08:33:37 AM UTC, comment #9: 

Dear Mr Spiralvoice,

Although it seems a bit better in 2.5.20, the memory leak seems to be still there. As I experimented, after a restart memory usage remained around 22 M with 6 files for half a day (which would never happen with 2.5.18, for example), but then began to grow. I did some searches and added 3 more files - however I am unable to confirm if this was what triggered the leak.

Anonymous
Tue 04 May 2004 07:21:43 PM UTC, comment #8: 

Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://savannah.nongnu.org/download/mldonkey/

spiralvoice <spiralvoice>
Group administrator
Sun 25 Apr 2004 06:22:45 PM UTC, comment #7: 

Dear Mr Spiralvoice,

I am greatly disappointed to see this memory leak issue go so far. This is a showstopper - I am shutting down two instances of mldonkey and switching to another program. Three friends of mine already did the same and I'm afraid mldonkey is loosing popularity quite fast in a broader sense too.

I am a Java programmer and I've been watching these threads for some time now. I've been experimenting with different versions without any improvement. Unfortunately, I am not in a position to actively help. I would only like to stress the importance that this bug needs fixing urgently (before any other) or the entire project may come to a halt.

If this is of any help: the last version that "worked" for me was 2.5.4 (consumed 30 M after 10 days up on RH 8.0 with machine still not swapping). On the same machine, 2.5.12 ate up entire RAM in less than a day.

Anonymous
Sat 03 Apr 2004 06:43:10 AM UTC, comment #6: 

well, i had severe issues with this, but i downloaded Spiral's 2.5.16f and it's been running for 60 something hours straight.

no more upload slot problems either  ;-)

however, now it seems to be consuming a big chink of memory and utilizing 99.9% of the cpu (well, one of them...) hoping it's just compiling a big file or something, but i've been staring at it for a few minutes now  :-(

i can't get in with telnet.  crap.  i think i saw a post somewhere about the cpu useage thing... any ideas?

Anonymous
Fri 26 Mar 2004 10:51:17 AM UTC, comment #5: 

There are some patches on Savannah which address upload slots problems but users reported that these also sloved their memory problems.

spiralvoice <spiralvoice>
Group administrator
Wed 18 Feb 2004 01:29:23 AM UTC, comment #4: 

My situation: P100, 48 Mb RAM, using 2.5-12. Self-compiled on RH8, enabled Overnet and SoulSeek. With 4 files to download (and 30 shared) MLdonkey starts with 9 Mb of memory and grows to about 15 Mb in 10 mins. This is reasonable: servers are connected, peer lists populated, downloads started and all functionality works. But after first 10 mins, memory is consumed at a constant rate of approx. 2 Mb/h, without any changes in speed/peers/servers/files.

Anonymous
Thu 15 Jan 2004 03:41:31 PM UTC, comment #3: 

The aforementioned log is only 3.4MB (!) when bzipped, so if an mlnet developer wants a copy, just drop me an email.

Joseph R. Kiniry <kiniry>
Thu 15 Jan 2004 03:26:43 PM UTC, comment #2: 

mlnet has now been running for ~28 hours.  Exactly two files are being downloaded (at ~2Kb/s), and five files are being uploaded (at ~21Kb/s).  mlnet is now using over 100Mb of resident memory:

kiniry    9368  0.9  9.8 107312 102420 pts/4 S    Jan14  17:01 ./mlnet -stdout

Attached are a number of additional statistics gathered via the web interface.  The debug log for these 28 hrs is 285MB uncompressed, so I'm obviously not attaching it.  I'll keep it for now so that if any developers was me to grep for specific subexpressions I can do so.

Joseph R. Kiniry <kiniry>
Tue 13 Jan 2004 01:14:01 PM UTC, comment #1: 
Joseph R. Kiniry <kiniry>
Tue 13 Jan 2004 01:10:01 PM UTC, original submission:  

I'm a bit surprised this has gone on as long as it has.  I see bug reports on bad leaks that go back almost 16 months.

I built the 2-5-4 release of mlnet with ocaml 3.06 (from RPM) on my RedHat 8.0 box.  The software was built and run under a 2.4 kernel for some time, but these days I run 2.6.

From config.log:
configure --prefix=/usr --mandir=/usr/share/man --infodir=/u
sr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit

gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

After running mlnet for several days memory usage grows tremendously.  The last time I restarted mlnet after a long period it was using 700MB of resident memory on my server.  I share and download only a handful of files (<10 each).  My bandwidth usage is minimal (typically << 5Kb/s each way).  All server settings are standard; e.g., I do not connect to an abnormal number of servers.

I am running again now and generating a verbose log for you.  I am going to ride this bug until something gets fixed.  It is not reasonable that this ugly issue is still a problem, especially in software written in OCaml.  I am happy to build and test CVS branches and the like for you.  I am also a good OCaml programmer.

Joseph R. Kiniry <kiniry>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #985:  Sources.txt added by kiniry (2KiB - text/plain - Sources list (after 28 hrs))
file #984:  Overnet.txt added by kiniry (3KiB - text/plain - Overnet list (after 28 hrs))
file #983:  Memory.txt added by kiniry (8KiB - text/plain - Memory usage (after 28 hrs))
file #982:  Gnutella.txt added by kiniry (286B - text/plain - Gnutella list (after 28 hrs))
file #981:  eDonkeyTable.txt added by kiniry (2KiB - text/plain - eDonkey Table (after 28 hrs))
file #980:  eDonkeyList.txt added by kiniry (3KiB - text/plain - eDonkey List (after 28 hrs))
file #979:  ConnectedServers.txt added by kiniry (2KiB - text/plain - Connected Servers (after 28 hrs))

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 13 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-08-24 spiralvoice Open/ClosedOpen Closed
2004-08-24 spiralvoice StatusNone Fixed
2004-08-21 spiralvoice Releaserelease-2-5-4
2004-08-21 spiralvoice Release2.00 2-5-21
2004-03-16 spiralvoice Dependencies- Depends on bugs #3761
2004-02-11 t8m Carbon-Copy- Added t8m
2004-01-15 kiniry Attached File- Added Sources.txt, #965
2004-01-15 kiniry Attached File- Added Overnet.txt, #964
2004-01-15 kiniry Attached File- Added Memory.txt, #963
2004-01-15 kiniry Attached File- Added Gnutella.txt, #962
2004-01-15 kiniry Attached File- Added eDonkeyTable.txt, #961
2004-01-15 kiniry Attached File- Added eDonkeyList.txt, #960
2004-01-15 kiniry Attached File- Added ConnectedServers.txt, #959

Back to the top

Powered by Savane 3.13-4448.
Corresponding source code