Memory Leak in .NET 1.1

[Greg Young]

I am showing the same behavior for the first example (6mb usage when done
running)

The second levelled off at around 6.3 mb after a minute or so.

Cheers,

Greg Young
MVP - C#

 

[Lebesgue]

I think I found the source of your problem:

try this:
for(int i=0; i<1000000; i++)
{
using(StreamWriter newMasterfile =
new StreamWriter(@"c:\XXX.tmp"))
{
newMasterfile.Close();
}
}

Console.WriteLine("done"); //<<<----

Console.ReadLine();

Does the memory usage grow after you see "done" on the console?
Didn't you just think the program was on the ReadLine line while it was
still in the loop?
It takes quite long to execute the whole loop - the memory usage is rising
all the time and then it remains the same - because GC can't run because the
only thread is stuck on the ReadLine() and it has no reason to run, because
there's no memory pressure.

 

[Willy Denoyette [MVP]]

Hmmm, looks like you don't know how the GC works, I tried to explain what
basically happens when you run this sample, for more details please refer to
my other reply in this thread.
Also, did you actually run the code?, and did you watch memory consumption
using perfmon?
The ReadLine is executed after the loop terminates, the GC cannot run while
in ReadLine(), but, while executing the loop, the GC kicks in several times
(per ~40 StreamWriter instances), so what you should see is a sawtooth-like
memory allocation pattern, starting at a certain level (~5Mb) and going up
to a maximum of ~6Mb (your mileage may vary).
Anyway, none of the programs posted are leaking.

Willy.

|I think I found the source of your problem:
|
| try this:
| for(int i=0; i<1000000; i++)
| {
| using(StreamWriter newMasterfile =
| new StreamWriter(@"c:\XXX.tmp"))
| {
| newMasterfile.Close();
| }
| }
|
| Console.WriteLine("done"); //<<<----
|
| Console.ReadLine();
|
| Does the memory usage grow after you see "done" on the console?
| Didn't you just think the program was on the ReadLine line while it was
| still in the loop?
| It takes quite long to execute the whole loop - the memory usage is rising
| all the time and then it remains the same - because GC can't run because
the
| only thread is stuck on the ReadLine() and it has no reason to run,
because
| there's no memory pressure.
|
| | > Good morning and thank you Greg!
| >
| > you'll find the files there:
| > http://savefile.com/projects/831693
| >
| > There are 2 files:
| > - MemoryLeak1: File with the original problem as described
| > - MemoryLeak2: A threading test with free main thread
| >
| > Just start the compiled release.
| > Is there anyone who can reproduce my problem?
| >
| > Martin
| >
|
|

 

[Lebesgue]

I know how the GC works and wrote what I wrote for the sake of simplicity.
I actually ran the code and saw no real memory leak - that's what I wanted
to express in my post. I am sorry you misinterpreted it.

 

[Willy Denoyette [MVP]]

|I know how the GC works and wrote what I wrote for the sake of simplicity.
| I actually ran the code and saw no real memory leak - that's what I wanted
| to express in my post. I am sorry you misinterpreted it.
|

Hmmmm, how could I correctly interpret this:

| It takes quite long to execute the whole loop - the memory usage is
rising
| all the time and then it remains the same - because GC can't run because
the

if you know how the GC works, you must known that the memory doesn't rise
all the time while executing the loop, because the GC kicks in several times
during execution.

Willy.

 

[Martin]

I've recognised now that we don't have a real memory leak. Anytime and
anyhow the StreamWriters will be kicked. Possibly I have to use on of
the GC methods - and that is not very reliable but the memory is free.
I always thought I don't have care about things like this because .NET
is good enough. Maybe I'll go back to the unmanaged world. There I know
what's going on :-(

But I've nevertheless have the problem: Our program is working like the
example (and that's running out of memory). The main thread of out
program is waiting in a console.readline() while the work (creating the
streamwriter) is done in a thread.

Now I look for an alternative construction. I'll avoid the
console.readline() in the main thread as you've suggested. Please look
at my secon example:
http://savefile.com/projects/831693

Why do I have the problem there? The main thread is looping delayed and
free to call the GC. The work (creating the streamwriter) is done in a
Thread. The breaking condition (console.readline) is in a second
thread. All the things I learned from the postings before is that I
will not have a problem in this situation. So why is my system running
out of virtual memory (also under pressure)?

Has anyone thought about the fact that we have the problem only in the
release configuration not in the debug?

Martin

 

[Martin]

To all of you who never have see an "out of virtual memory exception"
see:
http://www.savefile.com/projects/831693
I've placed some screenshots there. They're from the second example.

Maybe there is hope for you:
I've tested 10 systems yesterday with different configurations:
notebooks, VMware images, pcs and so on.

Nine of them leaked but there was one that was some different. You wont
believe: it was not leaking. It was a naked (no SP) WinXP (German)
VMWare Image. I had only installed the .NET 1.1 framework. So who is
the bastard on the others?

Please can you send me your system configuration to compare?

Thanks for all
Martin

 

[Willy Denoyette [MVP]]

| I've recognised now that we don't have a real memory leak.

Sure not, but what is your problem?

Anytime and
| anyhow the StreamWriters will be kicked. Possibly I have to use on of
| the GC methods -

No you don't, the GC methods are only needed in extreme rare cases, calling
them disturbs the GC allocation scheme when done without any good reason.

and that is not very reliable but the memory is free.
| I always thought I don't have care about things like this because .NET
| is good enough.

Sure it is.

Maybe I'll go back to the unmanaged world. There I know
| what's going on :-(
|

I hope you do, but I know that memory leaks are common issues in unmanaged
world .

| But I've nevertheless have the problem: Our program is working like the
| example (and that's running out of memory).

Not when I run it with V1.1.4322 SP1, on clean (no anti-virus crap) XP SP2 +
latest security updates, and on W2K3 SP1 latest security updates V1.1.4322
SP1 (ran it for 15 minutes).

The memory consumption stabilizes after a couple of minutes arround ~5.812
Kb "Memory usage" ~4.740Kb "VM size" .
The memory usage in debug mode is somewhat higher (~6800Kb/5356Kb)

You must have some other problem on your system(s).

Willy.

 

[Martin]

That's interesting.
I've a XP without SPs and the Framework 1.1.4322.573 also without SP.
It's stable! There must be something between those two.

 

[Willy Denoyette [MVP]]

| That's interesting.
| I've a XP without SPs and the Framework 1.1.4322.573 also without SP.
| It's stable! There must be something between those two.
|
For me it's stable on 1.1 with SP1 and without SP1 and V2.0.50727 too.
Really I don't believe your problem has anything to do with .NET, just try
to install SP1 on the box with V1.1 and try again, you can even install V2
and test again. Watch the CLR performance counters (CLR memory/ gen0, 1 and
2 collection frequency), the GC should run every once and a while.

Another suggestion is to stopt Norton AV, I noticed in the screendumps that
you run this on the system you used to run the failing test, could be wrong
though.

Willy.

 

[Martin]

I had systems with other virus software and systems without.
Thay all had the problem.

Do you have installed VS2003, Office or something like this?

try to install SP1 on the box with V1.1 and try again,

I'll do

you can even install V2 and test again.

It's install. As I told no prblem with 1.1 debug, 2.0 debug and
release.
There's only a problem with 1.1 release.

Watch the CLR performance counters (CLR memory/ gen0, 1 and
2 collection frequency), the GC should run every once and a while

It's running and counting but the objects are not freed. When I do the
GC.WaitForPendingFinalizers() it seems I reactivate something and it
cleans up. From this point everything works fine - no objects remain
anymore.