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

GC.Collect is documented as "Use this method to attempt to reclaim all memory
that is inaccessible. However, the Collect method does not guarantee that all
inaccessible memory is reclaimed".

I can't think of any reason why the GC won't collect all inaccessible memory.

WinDbg and SOS are a little more helpful at what you're describing.

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


"Ward Bekker" wrote:

"Peter Ritchie [C# MVP]" <PRSoCo (AT) newsgroups (DOT) nospam> wrote
The only thing that comes to mind is fragmentation.

GC.Collect typically does the collection and them performs a compaction.
When the heap is fragmented, that compaction doesn't work very well, and you
can end up without much "free" memory...

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

That shouln't cause a particular object to not be collected though.

My interpretation of "memory leak" could have been different than yours or
Ward's. Mine what that a particular object wasn't collected... I don't pay
attention to usable space as an indiciation of memory leaks. Due, as you
say, to fragmentation...

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


"Chris Mullins [MVP]" wrote:

I agree - this wouldn't at all cause something to not be collected.

The original poster should be able to use one of the existing tools
(Scitech's Memory Profiler, Red Gate's Memory Profiler, heck - even WinDbg
with SOS can do this), walk the root paths, and see why his object wasn't
collected. It should be pretty easy.

The tools have recently started getting so very good. Red Gate & SciTech now
have x64 support, SciTech can load in MiniDump files so you can do
post-crash memory analysis - it makes debugging so much easier than it used
to be.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise, Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

"Peter Ritchie [C# MVP]" <PRSoCo (AT) newsgroups (DOT) nospam> wrote

Thanks guys for your help,

More discussion of this thread can be found here:
news://news.microsoft.com:119/e0ZNz6... (DOT) phx.gbl

Hello,

Maybe you should rather use a memory profiler, such as dotTrace, for example?
That way you'll clearly see the objects that are “leaked” and trace the references
that are preventing them from being reclaimed.

(H) Serge

YourKit .NET profiler shows GC activity and has tools for memory leak
hunting
http://www.yourkit.com/dotnet/

GR,
Sergey