-
March 1st, 2011, 07:06 PM
#1
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...)
-
March 1st, 2011, 07:37 PM
#2
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.
-
March 1st, 2011, 07:46 PM
#3
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.
-
March 1st, 2011, 08:13 PM
#4
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.
-
March 1st, 2011, 08:33 PM
#5
Re: Leaking memory like sieve...
Bio....
Are you asking this for illustrative purposes? Or do you genuinely not know?
-
March 1st, 2011, 08:46 PM
#6
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.
-
March 1st, 2011, 08:52 PM
#7
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.
-
March 1st, 2011, 09:09 PM
#8
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.
-
March 1st, 2011, 10:25 PM
#9
Re: Leaking memory like sieve...
Originally Posted by 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.
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.
-
March 1st, 2011, 10:28 PM
#10
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
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|