Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / .NET Framework / CLR / May 2006

Tip: Looking for answers? Try searching our database.

Memory Not Being Claimed

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Mike King - 19 May 2006 13:24 GMT
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));
  }
}
Tasos Vogiatzoglou - 19 May 2006 13:48 GMT
I tried your example and it is collected (I tried it in a winform).
Mike King - 19 May 2006 14:14 GMT
>I tried your example and it is collected (I tried it in a winform).

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?
Tasos Vogiatzoglou - 19 May 2006 14:24 GMT
I think that the debugger causes this.

I can see the difference :)
Mike King - 19 May 2006 14:32 GMT
>I think that the debugger causes this.
>
> I can see the difference :)

Thanks!  I'm going to start a new thread over in
microsoft.public.vsnet.debugging.
Phil Wilson - 19 May 2006 17:49 GMT
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!

Signature

Phil Wilson
[Microsoft MVP-Windows Installer]

>>I think that the debugger causes this.
>>
>> I can see the difference :)
>
> Thanks!  I'm going to start a new thread over in
> microsoft.public.vsnet.debugging.
Mike King - 19 May 2006 18:09 GMT
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();
  }
}

> 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
[quoted text clipped - 10 lines]
>> Thanks!  I'm going to start a new thread over in
>> microsoft.public.vsnet.debugging.
Mike King - 19 May 2006 14:16 GMT
I forgot to mention that I'm using VS2003 with v1.1.

> Can someone please explain why the DataSet isn't being collected?  If I
> un-comment "dr = null", then the memory is freed.
[quoted text clipped - 25 lines]
>   }
> }
Tal - 23 May 2006 08:24 GMT
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 sh.t.

You should place an event handler to see when it does take place.
Ben Voigt - 25 May 2006 00:43 GMT
> 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 sh.t.

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. "

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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.