|
-
Oct 22nd, 2007, 07:54 AM
#1
Thread Starter
Frenzied Member
Memory Leaks
I'm looking for some feedback/thoughts/stories on tracking down memory leaks in managed code. (I know the GC handles lots of the typical cases but that doesn't mean it still can't happen).
I am particularly looking for opinions on what features would be most useful in a program that can detect a memory leak.
If you have had to deal with this issue before what strategy(ies) did you end up using to find it?
-
Oct 22nd, 2007, 11:55 AM
#2
Re: Memory Leaks
Stim,
You're right ... GC is a good feature - however it is not license to develop sloppy coding technique. GC is to be regarded as a "safety net", not as an invitation to leave your room a mess and expect it to be cleaned up by someone else.
I've always taught new developers the following axim (and started a few classes I taught in programming with it):
ASSUME NOTHING
and ...
K.I.S.S.
This goes for initializing variables, objects, opening file handles and database connections.
Having said that - whenever I am auditing a section of code that has a "suspected" memory leak I look for variable/object assignments, file/recordset opens or anything else that should be cleaned up when you're done with it.
GC should only be depended upon when the context of the object assignment requires that it exist beyond the context of it's creation - I.E. a function that creates the new object to be returned to someone calling it. Even there, the top level routine requiring such object creation should be coded in such a way that it attempts to clean up said object when it is finished with it.
- Any recordset (SQLDataReader, etc.) open should be paired with a Close().
- Any object that is created should be destroyed manually when done with it.
- Any file handle opened should be closed when done with it.
- Any database connection should be closed when done with it.
Finally - if the routine you're working with is so large that context can not continue to be understood by the developer then it should be refactored as soon as practical so it can be understandable and the context of the create/destroy pairs can be observed easily.
Just my 2-cents.
-Max
The name's "Peck" .... "Max Peck"
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." - Red Adair
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
|