Can someone please explain why the DataSet isn't being collected? If I
un-comment "dr = null", then the memory is freed.

using System;
using System.Data;

class Class1
{
[STAThread]
static void Main(string[] args)
{
DataSet ds = new DataSet();
DataTable dt = ds.Tables.Add("Customers");
dt.Columns.Add("custid", typeof(int));

for (int i=0; i<100000; ++i)
{
DataRow dr = dt.NewRow();
dt.Rows.Add(dr);
//dr = null;
}

Console.WriteLine(System.GC.GetTotalMemory(true));
dt = null;
ds = null;
System.GC.Collect();
Console.WriteLine(System.GC.GetTotalMemory(true));
}
}

I tried your example and it is collected (I tried it in a winform).

"Tasos Vogiatzoglou" <tvoglou (AT) gmail (DOT) com> wrote

Thanks for trying but can you do one more thing. I hope you're using VS
because now I think that's the key. If I create a "release build" there is
a big difference in memory usage between running the application by hitting
F5 and CTRL+F5. Can you verify the difference?

I forgot to mention that I'm using VS2003 with v1.1.

"Mike King" <emailMK (AT) excite (DOT) com> wrote

I think that the debugger causes this.

I can see the difference

"Tasos Vogiatzoglou" <tvoglou (AT) gmail (DOT) com> wrote

Thanks! I'm going to start a new thread over in
microsoft.public.vsnet.debugging.

Don't bother! Debug mode is very different. It adds code to keep objects
around. Do you really want your unreferenced objects to disappear while
you're trying to look at them in debug mode? Debug mode would be impossible
if your objects were being collected. In general, GC in debug mode follows
scope rules.

You can't do any memory testing with debug builds!

--
Phil Wilson
[Microsoft MVP-Windows Installer]

"Mike King" <emailMK (AT) excite (DOT) com> wrote

Thanks for the feedback.

I'm only talking about a "Release" build.

Yes, I would like the GC to collect unreferenced objects because if there is
not reference, then I cannot inspect it so what is the point. Also, how can
one inspect variables of a "Release" build anyway? I posted the following
to microsoft.public.vsnet.debugging.

#### BEGINNING OF MY PRIOR POST ####

I think I have figured it out. I _think_ Visual Studio 2003 is holding a
reference to reference types that are directly assigned to variables of a
method even if out of scope. The only exception is in a "Release" build and
the application is started without debugging. The code below is a simple
example of this behavior.

using System;

class Class1
{
[STAThread]
static void Main(string[] args)
{
WeakReference wr = null;
for (int i=0; i<1; ++i)
{
Uri uri = new Uri("http://domain.com");
wr = new WeakReference(uri);
}
System.GC.Collect();
Console.WriteLine(String.Format("IsAlive: {0}", wr.IsAlive));
Console.ReadLine();
}
}



"Phil Wilson" <pdjwilson (AT) nospam (DOT) cox.net> wrote

The GC process is a background process that runs on a different thread than your application.
Calling the GC to collect doesn't activate it explicitly.
Meaning you can't know when the GC will collect. You only know that it will happen. Multi threading kind of shit.

You should place an event handler to see when it does take place.

<Tal> wrote

You don't even know that. Finalizers don't have to run before the process
ends.

Take a look at "Managed Debugging Assistants" in the documentation:

"You can enable and disable MDAs by using a registry key, an environment
variable, or application configuration settings."
"By default, some MDAs are enabled when running the application attached to
a debugger, even without adding the registry key. "