Debugging a memory leak

[Guest]

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

 

[marc.gravell]

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

 

[marc.gravell]

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

 

[Guest]

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

 

[Chris Dunaway]

I'm using VB, so I guess I should use a try/fanally block mechanism ?

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.