C# Discussion Boards - CodeProject

28-Apr-07 22:45

Hi all,

For the last several days I've been trying to figure out why my windows mdi forms application doesn't tidy up resources correctly and continues to grow through multiple iterations of the same processes - ie Leaks Memory. To that end I created a small (single form) test Windows Application (TestGC). The TestGC form has 3 buttons (buttonShow, buttonShowDialog, buttonCollect) and a text box (textBoxMemory). The TestGC app was created as a standard vanilla app using VS (VS2005).

I added the following line to the form Dispose method

System.Diagnostics.Debug.WriteLine( "disp-"
+ HashIdent() + disposing.ToString() );

and the following code to the TestGC form class.

public readonly string testGCSource;

public TestGC( string testGCSource ) : this() {
this.testGCSource = testGCSource;
this.Text = HashIdent();
System.Diagnostics.Debug.WriteLine( "ctor." + HashIdent() );
}

public TestGC() {
this.testGCSource = String.Empty;
InitializeComponent();
}

private string HashIdent() {
return String.Format( "TestGC:{0}[{1}]",
this.testGCSource, this.GetHashCode() );
}

private void buttonShow_Click( object sender, EventArgs e ) {
(new TestGC( "Show" )).Show();
}

private void buttonShowDialog_Click( object sender, EventArgs e ) {
(new TestGC( "ShowDialog" )).ShowDialog( this );
}

private void buttonCollect_Click( object sender, EventArgs e ) {
this.textBoxMemory.Text = System.GC.GetTotalMemory( true ).ToString("N0");
}

~TestGC() {
System.Diagnostics.Debug.WriteLine( "dtor~" + HashIdent() );
}

What the simple test app demonstrates is that a form and all of its controls when displayed using the Show() method are NEVER destructed, they are Disposed(true) but not ever destructed. That is the class instance once created is never destroyed. This seems to be a total disaster (obviously not here, but for complex, multi-paged forms with perhaps hundreds of controls in mdi projects with many hundreds of forms) and is by every definition an example of a true memory leak. (The ShowDialog display method on form Close does call the destructor and gets fully GC'ed).

So my questions -

Is there any way to request of the GC why it will not specifically Finalize a class instance?

Is there any way to force the GC to Finalize (destruct) a Windows component? (Form + Controls).
(ie Is there a WinApi type dll call to force the Form (+ Controls) to go out of scope and be GC'ed?

From the above code it is obvious there are no 'local' references to any component after the Dispose method is called.

Thanks in advance,

David.

lmoelleb28-Apr-07 22:56

lmoelleb

28-Apr-07 22:56

Dispose will normally call SuppressFinalize[^] as it is doing the cleanup. This prevent the form being promoted to the next GC generation. Hence it is normal the destuctor is not executed, and it is certainly no disaster.

I do hope you are not using the task manager to determine the "leak" by the way?

coleydog29-Apr-07 5:18

29-Apr-07 5:18

I am using the Task Manager and it shows that each iteration of a new large form grows the exe memory usage by around 3MB (grows by 20MB during form execution, drops by around 17MB when the form is closed and GC.GetTotalMemory( true ) is called). After opening, running and closing just a few series of forms the app memory usage grows from 30MB to over 60MB, User Objects grows from 60 odd to over 130 and GDI objects grows from 80 plus to over 400. GC.GetTotalMemory( true ) returns around 7MB (Probably close to the correct value for chached data). I see that all class objects I create in the application are GC'ed except the forms and in the forms Dispose method I Close all appropriate objects and set all appropriate references to null.

My client requires that the application be run under Citrix and the application is expected to remain open on the user desktop for the whole day. That means that over the course of the day the application could grow by several hundred megabytes multiplied by the number of Citrix clients on the server to me adds up to a disaster.

lmoelleb29-Apr-07 7:03

lmoelleb

29-Apr-07 7:03

The Task Manager is useless for this. There are a number of performance monitors included, but I would recommend learning the details of the GC engine before trying to use them.

If your system is not currently memory limited, there is no reason for the garbage collector to kick in. It's not like unused memory is doing anyone any good, and the longer it can wait, the less risk of promoting data to new generations without need - after all, the more it has promoted, the harder it will be to release it if it is actually needed. I think I have seen claims it will be more inclined to free it if you minimize the app, but I have not looked into this.

As long as you have not left something hanging without calling Dispose I doubt you have a problem. And no need to run around setting things to null in the Dispose method by the way, this is not VB. If you no longer have a reference to you form, it will be cleared whenever the GC think it is best.

PS: Just realized another potential pitfall - if you have any delegates pointing to your form from an object not yet ready for GC, then it will keep your form alive. Typically this would be if your form was listening to an event in the domain layer. If it is the case, unsubscribe in the Dispose method.

coleydog29-Apr-07 20:03

29-Apr-07 20:03

OK so forms created with the VS designer have fields added to the form class to hold the instance creations of each of the controls added through the designer. Any events added during the designer phase are still active at the form Dispose stage. So there is a circular reference between the control event delegate ( textBox1.SomeEvent += new EventHandler(this.SomeMethod); ) and control create instance field ( TextBox textBox1; & this.textBox1 = new TextBox(); ) which prevails after the Dispose method is completed.

So I will at least need to add to the Dispose method

textBox1.SomeEvent -= new EventHandler(this.SomeMethod);

etc.

lmoelleb29-Apr-07 21:26

lmoelleb

29-Apr-07 21:26

No, this is not VB. Smile | :)

You need to unsubscribe from events on objects you still hold a reference to. If you do not keep a reference to the form once it is closed, the GC will be able to release it (if it can be bothered), no matter how many references it has to itself (or other objects for that amtter, as long as they combined can't be referenced anymore).

I am still feeling you are spending a lot of time solving a problem you do not know if you have in the first place.

coleydog29-Apr-07 22:40

29-Apr-07 22:40

I think maybe your right.

If I minimize the main mdi container form then maximize the task manager shows memory allocation has been reset to the expected minimum value. I guess the GC is saying its cheaper to do a full tidy up on minimize than save the untidied bloat to cache.

Thanks.

Christian Graus29-Apr-07 0:14

29-Apr-07 0:14

C# is not C++. Your destructor will be called, one day. Maybe before, maybe after your system collapses. To manage resources in C#, you need to call Dispose whenever disposing of any resource.

Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )

coleydog29-Apr-07 5:25

29-Apr-07 5:25

I have added a menu item to my Mdi container form which calls GC.GetTotalMemory( true ); and I report the returned value. GC.GetTotalMemory( true ) should force GC and the destructor (Finalize) as appropriate. This happens for all other class instances EXCEPT Forms displayed with the Show() method. (Modal Forms displayed with the ShowDialog method are GC'ed.)

Christian Graus29-Apr-07 10:52

29-Apr-07 10:52

You should never force the GC to run.

All forms, no matter how they are shown, are kept in memory to be shown again if they are reused. It's a waste of time worrying about the memory a form uses, are you using a ZX81 ? Just make sure you call Dispose as appropriate and trust the GC to do it's job.

coleydog29-Apr-07 16:36

29-Apr-07 16:36

Hi Christian,

Could you please have a look at my reply to CaiX message. No I am not using ZX81, however the client is using Citrix with some 150 user base so memory usage does impact server utilisation.

Also, how a form is shown does impact.

ShowDialog() does GC the form. (and only the internal Finalize() method calls Dispose as Dispose(false)

whereas

Show() automatically calls Dispose(true) on Close and never GC's the form.

Christian Graus29-Apr-07 18:15

29-Apr-07 18:15

OK, sounds like you're learning a lot about how the GC works. So, make your forms member variables, which is the only half reasonable way to create forms you call Show on, anyhow. Then, recycle the same form, instead of creating them all the time.

coleydog29-Apr-07 22:56

29-Apr-07 22:56

Thanks for your help.

I believe I've sorted the problem.

If I minimize and maximize the main mdi form the Task Manager reports a low resized memory. So the GC really only works when it needs too and if there is no memory pressure it just lets the app grow. Thanks.

caix29-Apr-07 14:11

caix

29-Apr-07 14:11

For most variables if you declare them in a function:

private void DoSomething()
{
MyClass yada;

yada = new MyClass();
}

Then yada gets garbage collected at the end of the function.
But if we do:
private void DoSomething()
{
Form2 yada;

yada = new Form2();
yada.Show();
}

Then yada doesn't get GC.
As Christian says, Dispose() will set it ready for GC, but it will take its own sweet time.
However do you really need to keep creating this form again and again, can't you declare it as an object in you main class, that you just show/hide when you need it. That will stop the memory allocation each time.

coleydog29-Apr-07 16:19

29-Apr-07 16:19

No, what I'm saying is this -

private void DoSomething()
{
(new Form2()).Show();
}
When Form2 is Closed (user action) Dispose(true) is automatically called by the CLR.

All fine. But after calls to GC.Collect() or GC.GetTotalMemory(true) (both of which should force GC) the form (plus all the controls for the form are never GC'd)

However,

private void DoSomething()
{
(new Form2()).ShowDialog();
}

When Form2 is Closed (user action) Dispose(true) is NOT automatically called by the CLR and shortly after, typically when further memory allocations are required the form gets CG'd.

My point is then that (new Form2()).Show(); requires that a reference to the form be promoted somewhere within the CLR (or O/S) to keep track of the form as the DoSomething() method completes immediately. The internal reference to the form is never removed, even when the form is closed (only when the app terminates) so the form (and all of the form's controls) can never be GC'd.

The typical base managed heap allocation for a complex form instance (multiple pages, multiple controls) appears to be around 1 to 2 megabytes (not including data) which remains after the form is Disposed. The application (an Mdi ERP solution) has around 500 forms and has a user base of around 150 users within the client organisation. The client decision to distribute the solution through Citrix is directly impacted by the cumulative effect of additional memory usage over 20 to 30 users on a typical Citrix server box.

So if no way can be found to force the CLR (or O/S) to relinquish the reference to the form after it is closed and therefore eventually be GC'd then the client decision to distribute the solution through Citrix will need to be seriously re-evaluated.

(Not the case for ShowDialog() which does not terminate the DoSomething() method until the form is Closed()) (therefore no promotion is necessary)

How to get Status of Process (Urgent)

Dave Kreskowiak29-Apr-07 16:55

Dave Kreskowiak

29-Apr-07 16:55

Instead of pounding on people to tell you something about your code, that they've never seen, why not test it out and beat on it until you get it to fail, or you manage to see that the GC does know what it's doing. The GC doesn't HAVE to collect objects if it doesn't see the need to, or, more precisely, it doesn't have to release managed memory back to Windows unless Windows wants it back.

If an object is collected, the memory goes back to the managed heap, not back to Windows!

Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007

Sanjib Raj28-Apr-07 22:18

Sanjib Raj

28-Apr-07 22:18

how to get status of process for checking if the process status is running or not.

Sanjit.rajbanshi@wlinktech.com

Re: How to get Status of Process (Urgent)

Amir Jalaly29-Apr-07 1:51

Amir Jalaly

29-Apr-07 1:51

Class
System.Diagnostics.Process
Can Help U.
by methods GetProcessesbyName & GetProcesses u can find a process
then by Process Properties Like HasExited u can find is running or some necessary information about process.

Regards Amir Jalaly

MVC custom control

alex.barylski28-Apr-07 20:22

alex.barylski

28-Apr-07 20:22

I want to develope a control following strict MVC principles. My experience in developing custom controls using MFC goes against my current understanding of formal MVC. I realize they are patterns which are meant to be interpreted, but MFC controls seem to have tight coupling of components in the MVC triad.

For instance, if I were to develop a custom control I would likely superclass from a CView (or some other superclass). That CView acts as both the controller and the view, and sometimes has a model as a composite.

I dislike that design and I think proper MVC implementation would reduce concrete depencies.

I have considered how this could be done in straight C and the Windows SDK - later wrapping the control in a CView storing the component in a DLL or similar - Like that editor already on here.

My question is:

If I choose to support Windows only and figure I'll take a stab at C# is implementing a custom control using a strict MVC implementation possible? Do we have any articles on here about using C# with just the SDK to get around restrictions set by frameworks?

Cheers Smile | :)

I'm finding the only constant in software development is change it self.

Re: MVC custom control

Christian Graus28-Apr-07 21:38

28-Apr-07 21:38

At the end of the day, a control will always be both view, and controller. I've done MVC in C#, but I didn't use the keyboard, I used custom input devices which I was able to write into controller classes, and decouple those from the view. But, as soon as I needed keyboard support, I had to code it into the controls, because, on windows, the controls get the keyboard input.

Re: MVC custom control

alex.barylski29-Apr-07 7:41

alex.barylski

29-Apr-07 7:41

I see what your saying, but I still find frameworks (MFC) non-conforming.

What i was thinking is developing the control using plain SDK (no framework) thus allowing me to keep strict seperation of all three components.

The controller would handle requests (via message pump) and invoke appropriate handlers which in turn would invoke the required models and update view(s).

Then I figured I could just wrap the DLL control as a CView. Obviously the control's API would expose many of the methods in the controller, model and view.

Is doing something like this possible in C#? Know of any articles on CP?

I'm finding the only constant in software development is change it self.

Re: MVC custom control

Christian Graus29-Apr-07 11:02