GC.Collect can be trusted?

[Ward Bekker]

Hi,

I'm wondering if the GC.Collect method really collects all objects
possible objects? Or is this still a "smart" process sometimes keeping
objects alive even if they can be garbage collected?

I need to know because I'm looking for memory leaks in an application.

It would be really helpful to be able to determine if an object after
manually invoking the GC.Collect is only kept alive because it still
being referenced by other alive objects in contrast to being alive
because the GC.Collect didn't found it necessary to collect the object,
even when asked explicitly.

Regards,

Ward

[Jon Skeet [C# MVP]]

On Apr 19, 3:42 pm, "Nicholas Paldino [.NET/C# MVP]"
<[e-mail] d.caspershouse. comwrote:

That's the thing though, if the object that you think should be garbage
collected is referenced by another object which is rooted (meaning you are
holding onto it some other way) and so on, then your object should NOT be
garbage collected. This is well-defined behavior for GC systems.

Yes, and I think that's Ward's point. He sees (in the profiler) an
object which he know should be garbage. There are three possibilities
here:

1) It is garbage, but it hasn't been collected.
2) It's not garbage, but should be, and there's a bug.
3) It's not garbage, and shouldn't be.

I believe the original question was trying to determine whether
calling GC.Collect() is a good way of removing option 1 from the
equation.
I suspect it's a good but not absolutely foolproof way. Calling
GC.Collect(), then GC.WaitForPendi ngFinalizers(), then GC.Collect() is
probably better, but I suspect there are still some situations where
it wouldn't help.

Jon

[Christof Nordiek]

"Christophe r Ireland" <ci******@gmail .comschrieb im Newsbeitrag
news:0B******** *************** ***********@mic rosoft.com...

Christof Nordiek wrote:

>Though garbage collection is very usefull to provent memory leaks,
this quote is a bit to optimistic. Sure ther can be memory leaks in
managed code. E.g. all static fields aren't collected. So any object
directly or indirectly referenced by a static field wouldn't be
collected. Also any variables very high in the call stack can prevent
referenced object from being collected, (though the lifetime of a
variable can be shortened by the compiler.)
By this a memory leak in managed code can easily construckted.

Interesting. Are you suggesting that the Microsoft Article 318263 I posted
a link to is somehow incorrect or misleading? Do you have any Microsoft
links which specifically refer to memory leaks in managed code?

Atleast it is a bit inaccurate about what is a memory leak.

Look furhter down in the same article:

"Additional ly, a project may only appear to have a memory leak. This
condition can occur if many large objects (such as DataTable objects) are
declared and then added to a collection (such as a DataSet). The resources
that these objects own may never be released, and the resources are left
alive for the whole run of the program. This appears to be a leak, but
actually it is just a symptom of the way that memory is being allocated in
the program.

For example, you have a DataSet. Every time that a new query is run, you add
a new DataTable element to that DataSet to hold the data that is returned.
If there are large amounts of data that you never dispose of, the data stays
alive as long as the DataSet is still in use. If this occurs enough times,
it is possible to run out of memory. This is not a memory leak, but instead
it is a problem in managing the memory."

If all the data loaded into the dataset mentioned is really needed still in
memory than this application simply needs so much memory and I's guess, it's
very badly designed.

On the other hand, if the older datatables aren't used anymore, but simply
remain in memory because they are referenced by the dataset, then I surely
would call this a memory leak.

What you should be cautious about is, if a shortly used objects are
referenced by a long living objects. For all if the objects are great and/or
there are much of them. Then should not remove those references to late or
forget to remove them at all.

HTH
Christof

[Peter Duniho]

On Thu, 19 Apr 2007 05:17:48 -0700, Christopher Ireland
<ci******@gmail .comwrote:

Ward Bekker wrote:

>My definition of a memory leak for managed frameworks:

All objects that should be garbage collected, but can't because they
are still referenced by other objects that will not be garbage
collected ;-)

The article I quoted suggests to me that there are no managed objects
that can't be garbage collected!

Anything to which a reference still exists "can't be garbage collected".
Which is good, because otherwise all of your objects would disappear the
first time the garbage collector ran. The garbage collector collects
anything that *can* be garbage collected, and so obviously there must also
be things that "can't be garbage collected" (that is, those things that
you're still using).

That's what Ward was talking about.

You obviously are really talking about "UNREFERENC ED managed objects that
can't be garbage collected", and I'd agree there are none of those. But
it seems to me that Ward made it pretty clear that's not what he's talking
about. He's talking about objects to which he still has references, but
*shouldn't*, and so they stay allocated even though they should have been
released.

It's a fundamentally different way of looking at the idea of a "memory
leak", but it's pretty much the only kind of memory leak you'd have with
managed objects and is still an example of a coding error (it's just that
the references are being kept when they shouldn't be, instead of being
lost when they shouldn't be :) ).

I hope that clarifies things.

Pete

[Jon Skeet [C# MVP]]

Christof Nordiek <[e-mail] ote:

Interesting. Are you suggesting that the Microsoft Article 318263 I posted
a link to is somehow incorrect or misleading? Do you have any Microsoft
links which specifically refer to memory leaks in managed code?

Atleast it is a bit inaccurate about what is a memory leak.

Look furhter down in the same article:

"Additional ly, a project may only appear to have a memory leak. This
condition can occur if many large objects (such as DataTable objects) are
declared and then added to a collection (such as a DataSet). The resources
that these objects own may never be released, and the resources are left
alive for the whole run of the program. This appears to be a leak, but
actually it is just a symptom of the way that memory is being allocated in
the program.

Basically what it's saying is that bugs can cause things which look
like memory leaks. Quite what it would include in the category of
memory leaks in unmanaged code if it excludes bugs is beyond me... a
memory leak is a bug pretty much by definition.

In short, it's harder to have memory leaks in managed code, but far
from impossible.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Christopher Ireland]

Christof Nordiek wrote:

Look furhter down in the same article:

>On the other hand, if the older datatables aren't used anymore, but simply
remain in memory because they are referenced by the dataset, then I surely
would call this a memory leak.

The article also says:
"Each time that this occurs, the amount of memory that the program is using
increases. The memory does not decrease until the end of the program or the
release of the objects from the collection. When you watch the program on a
performance monitor, this appears to be a memory leak, but it is not. The
program still has control over the memory but has chosen not to release it.
The fact that the program still has control prevents this from being a
memory leak, but the fact that the program keeps increasing the amount of
memory used can make it appear to be a memory leak. "

This suggests to me that a memory leak is only a memory leak when the
program loses control over the memory. As far as I understand, in a managed
environment this never happens (except in the case of a bug in the managed
environment itself).

This does not excuse, however, badly designed managed code which keep
objects alive unnecessarily and which gives the *appearance* of a memory
leak.
--
Thank you,

Christopher Ireland

[Christopher Ireland]

Peter Duniho wrote:

That's what Ward was talking about.

Thank you Peter, I think that's how I understood it.

You obviously are really talking about "UNREFERENC ED managed objects
that can't be garbage collected

No, I'm not.

>But it seems to me that Ward made it pretty clear that's not
what he's talking about. He's talking about objects to which he
still has references, but *shouldn't*, and so they stay allocated
even though they should have been released.

AFAIK, this can only mean a bug in the GC. Please see my reply to Christof.

It's a fundamentally different way of looking at the idea of a "memory
leak", but it's pretty much the only kind of memory leak you'd have
with managed objects and is still an example of a coding error (it's
just that the references are being kept when they shouldn't be,
instead of being lost when they shouldn't be :) ).

As I mentioned to Christof, I'm not excusing badly designed managed code and
I agree that such code can give rise to the *appearance* of a memory leak.

--
Thank you,

Christopher Ireland

[Christopher Ireland]

Jon Skeet [C# MVP] wrote:

Basically what it's saying is that bugs can cause things which look
like memory leaks.

That's certainly how I understood it.

>Quite what it would include in the category of
memory leaks in unmanaged code if it excludes bugs is beyond me... a
memory leak is a bug pretty much by definition.

In unmanaged code it would be a bug in your code, in managed code it would
be a bug in the GC, no?

In short, it's harder to have memory leaks in managed code, but far
from impossible.

I agree, but I think I was simply trying to say that real memory leaks in
managed code are due to bugs in the framework rather than bugs in your code
(making the distinction between bugs and badly designed code here (somehow
<g>)).

--
Thank you,

Christopher Ireland

[Jon Skeet [C# MVP]]

Christopher Ireland <ci******@gmail .comwrote:

Basically what it's saying is that bugs can cause things which look
like memory leaks.

That's certainly how I understood it.

Quite what it would include in the category of
memory leaks in unmanaged code if it excludes bugs is beyond me... a
memory leak is a bug pretty much by definition.

In unmanaged code it would be a bug in your code, in managed code it would
be a bug in the GC, no?

No - the kind of leak they're talking about is caused by a bug in your
code, by keeping a reference in another (uncollected) object.

As for bugs in the GC - a memory leak due to that would be similar to a
memory leak in MFC or a 3rd party library.

In short, it's harder to have memory leaks in managed code, but far
from impossible.

I agree, but I think I was simply trying to say that real memory leaks in
managed code are due to bugs in the framework rather than bugs in your code
(making the distinction between bugs and badly designed code here (somehow
<g>)).

If they *are* saying that, then I disagree - it's easy to assign
something to a static variable and forget about it. You'll then
potentially have what looks like a memory leak, and it would certainly
be due to a bug in your code. Not a failure to call free(), but a
failure to effectively make the object eligible for garbage collection.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Christopher Ireland <ci******@gmail .comwrote:

But it seems to me that Ward made it pretty clear that's not
what he's talking about. He's talking about objects to which he
still has references, but *shouldn't*, and so they stay allocated
even though they should have been released.

AFAIK, this can only mean a bug in the GC. Please see my reply to Christof.

No, it doesn't mean a bug in the GC. It almost certainly means a bug in
Ward's code, where he's got a reference to an object even though his
design (or whatever) says that he shouldn't. I believe he's trying to
track down that bug. Read Peter's sentence very carefully:

<quote>
He's talking about objects to which he still has references, but
*shouldn't*, and so they stay allocated even though they should have
been released.
</quote>

If he still has references to the object, it shouldn't be garbage
collected, so it can't be a GC bug.

It's a fundamentally different way of looking at the idea of a "memory
leak", but it's pretty much the only kind of memory leak you'd have
with managed objects and is still an example of a coding error (it's
just that the references are being kept when they shouldn't be,
instead of being lost when they shouldn't be :) ).

As I mentioned to Christof, I'm not excusing badly designed managed
code and I agree that such code can give rise to the *appearance* of
a memory leak.

And that's the situation I believe Ward is in.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Christopher Ireland <ci******@gmail .comwrote:

<snip>

This suggests to me that a memory leak is only a memory leak when the
program loses control over the memory. As far as I understand, in a managed
environment this never happens (except in the case of a bug in the managed
environment itself).

That seems like a fairly arbitrary definition of "memory leak" to me (I
know it's not yours) and not a terribly useful one. I find the
wikipedia statement clearer:

<quote>
In computer science, a memory leak is a particular kind of
unintentional memory consumption by a computer program where the
program fails to release memory when no longer needed.
</quote>

Certainly a *user* couldn't care less whether their memory is being
eaten due to references that are still available or due to memory which
no code knows about - and it doesn't make huge odds when it comes to
debugging, either.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too