Not Freeing Memory

Not Freeing Memory

• Priyank001

  But this would solve the problem only if the exceptions were occuring in the first place.
  
  However, adding the dispose in a finally block and to use 'using' are good suggestions and documented best practices - its anyway a good thing to adopt those suggestions.
  
  Regards,
  Vikram

  
  
  

• TGirgenti

  Hi James,
  
  Thanks. I have had a look and can't seem to find GC.Collect() within the code. Running through the memory profiler, the garbage collector is collecting instantly after it previously freed some memory. To try and picture this, it starts off at the bottom left corner and increases rapidly diagonally up the screen freeing memory and then the app throws an out of memory exception, before the plugin dies.
  Its the first time we are really doing anything with lots of images. We seem to have no problems working with a couple of images.  
  
  We are using Microsoft .NET Framework 1.1. 
  
  I will take a look at Rico Mariani's blog entry.
  
  Many Thanks,
  Bruce
  
   
  
  

• Mike Champion

  Hi Vikram,
  
  Many thanks!! I will try that and see what happens. I am fairly new to garbadge collection in C# as i come from a Java background, which takes care of it quite well.
  
  Cheers for your help,
  
  Bruce
  
  

• IainDowns

  Hi Dundy,
  
  I recommend u try to figure out using the CLR Profiler:
  
  CLR Profiler:
  http://www.microsoft.com/downloads/details.aspx FamilyId=86CE6052-D7F4-4AEB-9B7A-94635BEEBDDA&displaylang=en
  
  The download also includes a help file which teaches u how to use it.
  
  Regards,
  Vikram
  
  

• Randy J

  Interesting problem. The only time that I've seen this type of behaviour is if one is trying to outsmart the GC by calling GC.Collect() manually rather than letting the GC's heuristics take care of it. So I would do a search in your code for "GC.Collect" and comment those out. I would also recommend reading Rico Mariani's blog entry on "When to Call GC.Collect()". I would highly recommend all his performance articles.
  
  

• tgorrie

  Hi All,
  
  I want to thank you for all of your suggestions, after some time today, we managed to find the problem, which was the memory manager is collecting far too often thus slowing down the system to a halt. So when printing a lot of the images out to the memory stream, it goes hay wires collecting the memory back and slowing the performance down. The memory manager then gets to a point that it has been called soo many times it seems to die.  So at the moment, looking at what i can do to stop this.
  
  Thanks,
  Bruce
  
  

• AustinStephens

  Hi,
  
  How does one file bugs or locate curret bugs with microsoft products
  
  Many Thanks,
  Bruce

  
  
  

• Yuriy Gudz

  Amusingly, Vikram and I posted the same link at the same time. +1, Vikram.
  
  

• Al Lee MSFT

  Can you post a snippet of how you are disposing
  Try calling GC.Collect() and see if that changes anything.
  
  Regards,
  Vikram
  
  

• KennsterDude

  You might want to verify that it is in fact the Bitmap image that is taking up the memory and not some other object (like the rendered report, for example - hard to say without knowing more about your app). Grab the CLR Profiler from Microsoft Downloads and take a look at which objects are left hanging around after your above code runs. Vikram's idea of calling GC.Collect() is good for troubleshooting, but I would avoid using it in production code. Better to find out the root cause of why the GC isn't cleaning up as quickly as desired rather than trying to outsmart it by calling GC.Collect().

  
  
  

• Souhil Benammour

  Hi Vikram,
  
  Via our plugin we are generating a report. We extract scans from our selection pool and add them to a report.
  
  BodyMappingWrapper bmw = (BodyMappingWrapper)wrapper;

  bmw.SIAgraphType = BodyMappingWrapper.ImageType.COLOR;

  nonContactImages[0] = (Bitmap) bmw.Image;

  try

  {
   //add image to report

     bmw.Image.Dispose();
  }

  
  
  

• mnlarsen

  Dundy,  This is probably not the source of your problem, but I did notice something in your code that could cause this unexpected behavior.  You are disposing the image within the try block.  Ask yourself, "What happens if an exception is thrown "  That's right, the image is not Disposed.  Two possible solutions:
  
  1.  Put the "bmw.Image.Dispose()" in a finally block.
  2.  Add a "using( bmw)" block.
  
  PS  Is it possible that the nonContactImages[0] reference is preventing it from being disposed   I don't know a lot about how Dispose() functions.
  
  

• MattMc3

  Hi Bruce,
  
  For Visual Studio 2005/ .NET Framework 2.0
  http://lab.msdn.microsoft.com/productfeedback/legal.aspx fwd=rep
  
  For Visual Studio.NET 2003, you will need to contact ur local Microsoft Support and open a case with them.
  
  Regards,
  Vikram
  
  

• Tranzistors

  Overall the .NET GC does quite well too. It's biggest challenge is unmanaged memory as it has no way of knowing how much unmanaged memory was allocated. (The Java GCs would likely have the same problem as they don't have hooks into native APIs either.) .NET Framework 2.0 added a new method, GC.AddMemoryPressure(long bytesAllocated), which tells the GC that there are an additional bytesAllocated-worth of unmanaged memory that the GC doesn't know about. This allows the GC's heuristics to better tune GC collections. The problem in .NET Framework 1.X was that you might have an API that allocates a managed handle worth a few dozen bytes, but holds onto a large chunk of unmanaged memory allocated through a Win32 API call or other mechanism. The GC decides not to run because it will only free up a few dozen bytes whereas there are a few megabytes of unmanaged memory underneath the surface.
  
  Even in 1.0 and 1.1, the GC is compacts the heap, maintains good locality and performance through generations, has a separate large object heap to minimze the cost of moving large objects during heap compact, etc.
  
  My point is that the .NET GC is quite well-thought out and performant. Don't think the .NET GC is sub-par due to what is most likely a bug in a bitmap class.
  
  
• Not Freeing Memory