locked
Doubt in Remote Performance Monitor RRS feed

  • Question

  • Hi,

          I am using Remote Performance Monitor to check memory leaks.

    How to find out the name of the instances from my application that causes memory leaks?

     

    I read steven blog from http://blogs.msdn.com/stevenpr/   which explains using of RPM.

     

           The title regarding "The Roots Tree " from that blog explains to find the instance that cause memory leaks.

     

    Can somebody explain it more how to find the particular instance that causes memeory leaks?

     

    I am using RPM of Netcf V 2.0 with Service Pack  2.0

    Thursday, April 5, 2007 1:03 PM

Answers

  • You can run your application under RPM and try to get heap dump at the moments where you know in what state your application is (e.g. after a sertain button was pushed or when application expects input from user and all threads are suspended).

    The best would be such a point in code where you know memory state should be stable, without additional live objects in next iteration compared to previous. Then if there are any additional objects in second heap dump compared to first one, that means those are leaking. Or if you know what additional objects should appear between two iterations, filter them out and examine the rest: leak should be somewhere there.

    From that data you should be able to figure out root which is causing the leak (object's type and is it a static variable or variable on stack,...), but this tool won't give variable name for it. Is it what you are asking about?

     

    Thank you,

    Natalia Glagoleva, MSFT 

          

      

    Monday, April 16, 2007 11:15 PM

All replies

  • You can run your application under RPM and try to get heap dump at the moments where you know in what state your application is (e.g. after a sertain button was pushed or when application expects input from user and all threads are suspended).

    The best would be such a point in code where you know memory state should be stable, without additional live objects in next iteration compared to previous. Then if there are any additional objects in second heap dump compared to first one, that means those are leaking. Or if you know what additional objects should appear between two iterations, filter them out and examine the rest: leak should be somewhere there.

    From that data you should be able to figure out root which is causing the leak (object's type and is it a static variable or variable on stack,...), but this tool won't give variable name for it. Is it what you are asking about?

     

    Thank you,

    Natalia Glagoleva, MSFT 

          

      

    Monday, April 16, 2007 11:15 PM
  • Hi Natalia,

     

                      This is what is asked.Thanks for the information.

     

     

    Tuesday, April 17, 2007 5:03 AM