CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 10 of 10
  1. #1
    Join Date
    Jun 2002
    Location
    Monte Carlo
    Posts
    129

    Question Leaking memory like sieve...

    I know I have a memory leak. Best case, I get an "OutOfMemoryException", worst case, the app just vanishes.

    I'm dealing with legacy code, a lot of threads, a lot of data items.

    For a high level "first pass" in solving the problem, I thought I'd ask the gurus here on what are the "tell tale" signs of bad coding practice that would lead to this behavior. I've already discovered that NOT unhooking events could lead to memory leak behavior, but I'm asking if any other good "rules of thumb" exist.

    I want to start looking for memory leaks in the morning at work. I'll use a profiler, but I think that sloppy coding might be easier to spot at first.

    What are the tell tale signs of a memory leak/resource consumption foul in a C# app? (This app does touch unmanaged code from time to time...)

  2. #2
    Join Date
    Jun 2008
    Posts
    2,477

    Re: Leaking memory like sieve...

    First off, you have the right idea; use a profiler. There is no sense in making guesses if testing out your hypotheses is non-trivial. Aside from that, the most common ways to "leak" memory in a .NET are:

    1. Not disposing (i.e., calling Dispose()) of objects that implement IDisposable. The finalizer will call Dispose eventually, but it is not deterministic because there are no guarantees about when the GC will reclaim the object/call the finalizer and it will never happen if you leave stale references to them lying around.

    2. An extension of #1; stale references. As you have learned in regards to delegates, a poorly designed program may have a lot of 'stale' references to objects lying around that are no longer needed. That will prevent the GC from reclaiming that memory.

  3. #3
    Join Date
    Jun 2002
    Location
    Monte Carlo
    Posts
    129

    Re: Leaking memory like sieve...

    Thanks, Ed.

    I didn't mention that this is a mobile app and using a profiler for one of those is like fifty million times harder than using a profiler for a normal app. And this is the type of application that absolutely cannot be run in an emulator.

    Like I said, I'll use a profiler as a "zombies at the door last approach", but I'm hoping that the "bad practices" come to light with visual inspection.

    One can hope.

  4. #4
    Join Date
    Feb 2011
    Location
    United States
    Posts
    1,016

    Re: Leaking memory like sieve...

    Just to clarify (since this situation seems rare enough...), what is the effect of doing something like:

    Code:
    IDisposable dispObject = //Get a disposible object;
    
    dispObject = null; //Drop the reference for the GC
    while ( true )
    {
        //Unrelated stuff
    }
    Will the GC reclaim dispObject on it's next cycle?
    Best Regards,

    BioPhysEngr
    http://blog.biophysengr.net
    --
    All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

  5. #5
    Join Date
    Jun 2002
    Location
    Monte Carlo
    Posts
    129

    Re: Leaking memory like sieve...

    Bio....

    Are you asking this for illustrative purposes? Or do you genuinely not know?

  6. #6
    Join Date
    Feb 2011
    Location
    United States
    Posts
    1,016

    Re: Leaking memory like sieve...

    Um, both, I guess. I thought I knew the answer (GC will see the lost reference and automagically call Dispose to free the memory when it cycles though), but Ed's answer led me to doubt that so I tried to construct as simple an example as possible to ask.

    I guess I was mostly confused about what "stale reference" meant exactly.

    Better to ask and be thought foolish once than leak memory forever being wrong. :-)
    Last edited by BioPhysEngr; March 1st, 2011 at 08:49 PM. Reason: clarify
    Best Regards,

    BioPhysEngr
    http://blog.biophysengr.net
    --
    All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

  7. #7
    Join Date
    Jun 2002
    Location
    Monte Carlo
    Posts
    129

    Re: Leaking memory like sieve...

    Cool story, Bio...

    To reiterate, I am looking for rough "code signatures/profiles" that one can peruse in an .NET app and spot a memory leak. I thank Ed and Bio for their input so far, as it as given me a good starting point.

    Any other suggestions are most welcome.

  8. #8
    Join Date
    Feb 2011
    Location
    United States
    Posts
    1,016

    Re: Leaking memory like sieve...

    I think profiling is probably the way to go. You might also look for any code in an unsafe block (informative link).

    Here's a blog post on the subject, but he basically said what Ed said: http://blogs.msdn.com/b/davidklinems...16/493580.aspx

    Here are some free, open-source profilers: http://csharp-source.net/open-source/profilers
    Best Regards,

    BioPhysEngr
    http://blog.biophysengr.net
    --
    All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

  9. #9
    Join Date
    Jun 2008
    Posts
    2,477

    Re: Leaking memory like sieve...

    Quote Originally Posted by BioPhysEngr View Post
    Um, both, I guess. I thought I knew the answer (GC will see the lost reference and automagically call Dispose to free the memory when it cycles though), but Ed's answer led me to doubt that so I tried to construct as simple an example as possible to ask.
    Setting the reference to null will make it eligible for garbage collection because (as long as it was the only one) there is no longer a reference to the object in the managed heap.

  10. #10
    Join Date
    Feb 2011
    Location
    United States
    Posts
    1,016

    Re: Leaking memory like sieve...

    Okay, just wanted to make sure. Thanks.
    Best Regards,

    BioPhysEngr
    http://blog.biophysengr.net
    --
    All advice is offered in good faith only. You are ultimately responsible for effects of your programs and the integrity of the machines they run on.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured