Obviously hefty memory leak

[GoogleCodeExporter]

Description of the issue:
 After ripping for some hours, the last ripper crashes awfully. Often it 
pops up with a dialog, stating "an expected exception occurred" - note the 
"_expected_". When checking in with Process Explorer, it at that point uses 
above 1.1 GB in Working Set memory, and the exception is thus most probably 
Out Of Memory - since my box has 2GB Ram and I have a bunch of other stuff 
running too.

What steps will reproduce the problem?
1. I set up and log in
2. I tune in to my personal tag "loved"
3. After some hours, it crashes.

What is the expected output?
No crash, and no memory bloating during use, at all, whatsoever.

GENERAL INFORMATION ABOUT YOUR SYSTEM:

TheLastRipper version?  1.4.0
Mono/.Net runtime version? I at least have this folder: 
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
Operating system and version? Windows XP SP3, fully up2date at this date.

Some aspects of settings for last ripper: No proxy, Listening at port 8000, 
Savemode Buffer in mem, after save to disk, save to a share residing on a 
linux box, Skip existing music, use quarantine directory, after rip "C:\Program 
Files\Winamp\Winamp.exe" /add "%F", no MP3tunes.

It must be possible to attach a profiler and dump memory after an hour of 
ripping to see which objects are lingering? I don't know .NET, but that's 
what I'd do on Java..

Original issue reported on code.google.com by stolsvik on 27 Apr 2009 at 9:39

[GoogleCodeExporter]

I too have this issue. If you leave task manager open and watch the memory 
usage, you
can see it rise and rise until a crash when your system has no more memory to
allocate to the program. HUGE memory leak. Needs to be fixed ASAP. 

Windows 7 build 7201. 

Original comment by cho...@gmail.com on 11 Aug 2009 at 4:49

[GoogleCodeExporter]

Well, I have started working on tracking down this memory leak. The issue seems 
to originate within liblastrip and the LastManager class within the 
LastManager.Save. The memory seems to be lost in the byte[]. I will see if I 
can zero out the byte[] when the song is completed saving, returning the memory 
to the OS. 

Original comment by arunpere...@gmail.com on 26 Jul 2010 at 5:06

[GoogleCodeExporter]

Attached an image that includes a class reference image. The in-memory saved 
data probably doesn't get gc'ed or does get marked for de-allocation but 
doesn't. Will update when I have a fix for the issue. This seems like the best 
place to start. 

Original comment by arunpere...@gmail.com on 26 Jul 2010 at 5:10

Attachments:

• Callgraph-lastripper.png

[GoogleCodeExporter]

running version 1.4.0 and still seeing this bug, works fine for a few hours 
then crashes. would be nice if I could leave it running overnight to use up the 
cheap bandwidth :)

AFAIK proper memory disposal is impossible in C#, but you should still be able 
to trick the OS into doing something about it using IDisposable; have a look at:
http://stackoverflow.com/questions/1452096/c-how-to-implement-my-own-byte-array-
creation-and-disposal
(if you haven't seen it already,) or try a colossal using block somewhere.

my system is just an XP VM with about a Gig of RAM sliced from my Mac; so I am 
insulated from the particularly painful system instabilities that you get when 
this bug strikes.

I have tried getting it to write to disk rather than buffer in RAM, but then it 
just crashes as soon as it starts streaming, sadly. This would in theory solve 
the problem.

I don't have time to look into a proper fix at the moment, but if it is still 
unresolved in January I might take a look.

Original comment by joe.jord...@gmail.com on 25 Nov 2010 at 11:11

[GoogleCodeExporter]

It's probably still unresolved in January... But I'll happily grant you svn 
commit access if you want to hack on it... I don't have time for hacking 
TheLastRipper anymore...

Original comment by jopsen@gmail.com on 28 Nov 2010 at 9:52