Leaking memory like sieve...

[mega Kluge]

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...)

[BigEd781]

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.

[mega Kluge]

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.

[BioPhysEngr]

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

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?

[mega Kluge]

Bio....

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

[BioPhysEngr]

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. :-)

[mega Kluge]

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.

[BioPhysEngr]

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

[BigEd781]

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.

[BioPhysEngr]

Okay, just wanted to make sure. Thanks.