Win32 Heaps keeps on Growing

Win32 Heaps keeps on Growing

• ruvyzzang

  Michael Chroman, i don't agree with you. The GC will remove the object called a when it is out of scope/don't have any references.
  
  
  

• mike1942f

  I'm definetly sure that we are not doing any API Calls.

  Also I'm fairly sure that we are distroying all objects.

  We are keeping references in a Queue. But I was under the impresion that these references would be removed when calling Dequeue.

  I must note that:

  The objects are created in one Thread ->

  Enqueued in that Thread ->

  Dequeued in a Worker Thread and the values are used to do a Database Update.

  Any other ideas

  
  

• Paul McKeown

  Do you have a loop that creates an object with each iteration If so, then it is more than possible that each of those objects do not get destroyed. e.g.

  for(int i =0; i < SomeObject.Length; i++)

  {

  object a = new object();

  a.....

  }

  If that is the case, try replacing with something like

  object a = new object();

  for(int i =0; i < SomeObject.Length; i++)

  {

  a = (object)SomeObject;

  a.....

  }

  
  

• Ronnie Smith

  Nope we are not using any COM objects or p/invoke's.
  

• Harish

  We can't smell it here, it are allways objects that still have some references or handles that arn't be closed.
  
  It is very hard to find memory leaks, but i think there is no other way to get a good memory profiler, get some coffee and start the long journey.
  Try do clean up as much as posible, allways dispose things when they arent needed anymore and implement you classes that give problems with the Dispose Pattern so whey will be cleanedup nicelly, but only do this when needed!
  
  Because you use multiple threads, are you sure there arend any deadlocks.. etc, it sounds hard but you will have a long night finding the leaks.
  
  
  

• igor123

  As i asked before, are you sure there a no deadlocks
  
  
  

• frohar

  I assume you already have been montiring the memory problem using the performance wizard in VS2005. This will show where your memory are allocated. In order to track down where it is NOT discarded, you can use a utility called "Son of Strike", a debugger extension to Visual Studio. A collegue of mine used this to track down a similar problem half a year ago, I've not used it myself, but he succeeded rather quickly to solve the problem with this tool.

  You can find it and and article about it here : http://msdn.microsoft.com/msdnmag/issues/03/06/bugslayer/default.aspx

  You need to enable "Unmanaged debugging" in Project properties, and then set a breakpoint where you assume that your memory should have been released.

  At the stop, go into Debug->Windows->Immediate Window and give the following command:

  .load sos

  then

  .dumpheap -type whatevertypeyouareinterestedin

  Now you will see list of objects. If you assume zero and still see objects, they are surely well and alive

  In the list they will be shown with their address

  Then use

  .gcroot -nostacks address

  where address is picked from the list resulting from the dumpheap command

  You will get a possibly very long list.

  All entries with HANDLE(WeakLn) should be ok, taken care of later by the GC.

  However, entries with HANDLE(pinned) will NOT be released by the GC.

  And they will probably be the culprits you're looking after.

  Ad the others have said, this is not a quick job, but with the SOS tool you will at least have a better paved road !

  
  

• DRoden

  are there any COM objects or p/invoke's
  

• Farpetrad

  Hundreds of things could cause this. Most likely (IMHO)
  
  * Calling Windows API functions that directly or indirectly allocate memory, and not cleaning up.
  * Creating objects and never disposing of them (and keeping references to them in, for example, an ArrayList or some other dynamically sized object).
  
  
  
• Win32 Heaps keeps on Growing