 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Windows Forms / WinForm General / August 2006Debugging a memory leak
Hi, I have a memory leak (or at least had one) in my App. I've now added several Dispose methods to different places, eg I now dispose all SQLCommands, DataAdapters etc. So in theory I have fixed the problem. But how can I verify that, since the GC process runs whenever it feels like it. If I look at task manager, my App still consumes something like 4 Mb on each transaction the user does, and if I then stop and wait for the memory to be reclaimed, it doesn't seem to happen. But if I then insert a breakpoint into the source, and run another transaction step by step, there is a good change that somewhere in the middle of that the GC kicks in and suddenly I have a 20 Mb something smaller momery footprint. My problem is that I can't see that happen in normal operation, only when I step through the code step by step. Petri First: adding .Dispose() calls can *still* (unless done very carefully indeed) lead to abandoned objects, particularly when exceptions are thrown. The best way to manage IDisposable objects is via "using", as then it is disposed regardless of success / failure. Second (and this applies to your other GC post): I have yet to /happily/ recommend messing *at all* with GC's operation; let it be. It has a pretty good handle on what it is doing, and why, and when. Third: I would start to look at *why* each transaction is taking 4Mb; this seems quite a sizeable bit of memory, so I would look at what I am doing? e.g. * Am I using string concatenation to create long strings with lots of concatenations (a well-documted memory goof)? If so, StringBuilder etc are your friend. * Am I working with large arrays when streaming objects (using smaller byte[] buffers) would be more appropriate? * Am I using (for example) XmlDocument objects on *huge* xml, for little purpose? then XmlReader / XmlWriter usage would be more efficient. etc Look at *why* your code is so memory-hungry *first*, then (and *only* then) look at asking the runtime to "play nice with the fat kid". Marc I'm using VB, so I guess I should use a try/fanally block mechanism ? Part of the stuff that the program does, is that it reads stuff into a dataset. After it's done the dataset is reset, but not disposed as the same object is to be used with the next transaction. When this occurs does the GC reduce the size of the memory it reserves for the dataset (ie at some point it has 2 MB reserved for the dataset, can it shrink to few 100 Kb after the dataset is reset). The GC behaviour does not make sense to me, as at some point the memory consumption has gone as low as 9 MB, and then a few transactions later it is up to 50 MB and it then stays there. Now I've also managed to see behaviour where a transaction actually lowers the memory. Ie just a moment ago a transaction caused the memory to drop from 43 MB down to 41 Mb > First: adding .Dispose() calls can *still* (unless done very carefully > indeed) lead to abandoned objects, particularly when exceptions are [quoted text clipped - 26 lines] > > Marc > I'm using VB, so I guess I should use a try/fanally block mechanism ? > > > First: adding .Dispose() calls can *still* (unless done very carefully > > indeed) lead to abandoned objects, particularly when exceptions are > > thrown. The best way to manage IDisposable objects is via "using", as > > then it is disposed regardless of success / failure. You didn't say which version of VB you are using, but if you are using VB 2005, then you can use the Using End Using statements which are equivalent to C#'s using statement. Oh - and further: I doubt the commands and adapters (etc) are contributing much to this glut of memory, unless you are executing the same SQL command 5000 times but creating a new SqlCommand each time, in which case the answer is to re-use the same SqlCommand a few times... Marc Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.