Re: Releasing Memory - C# Discussion Boards

Re: System.Xml.Document : How to write special characters in an xml file ?

28-Sep-05 6:24

I don't think you can get it to retain the whitespace when it's read. Special characters will not get interpreted as whitepsace either.

I'm curious, why would you want the whitespace in there? I can't think of a reason to do it.

You MIGHT be able to get away with putting in attributes into your nodes that specify how many spaces to put into the data when you retrieve the data. Something like:

<element>
    <subElement wsPrefix=8 wsPostfix=3>mydata</subElement>
</element>

When you go to retrieve the element, read the wsPrefix and wsPostfix attributes and add the number of spaces to your data accordingly.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

smashingraph28-Sep-05 21:50

smashingraph

28-Sep-05 21:50

Hi, thanks for your idea, I will think about it.

The reason I need a white space is because I have some subElements that I want to concatenate
like "someData"+WHITESPACE+"someData".

for example:

<element>
<subElement type="data">someData</subElement>
<subElement type="caption"> </subElement>
<subElement type="data">someData</subElement>
</element>

I found this really weird that the xmlReader does not interpret one or more whitespace in the Innertext part of an element... don't you think so?

Releasing Memory

dbetting28-Sep-05 3:30

28-Sep-05 3:30

I have been trying to figure out a memory leak for quite some time. I've ignored what C# is supposedly taking care of but now that is the only thing I have left. And...I discovered something I'm confused about.

Add a new form to a project and drop some components on it. You will find
private System.ComponentModel.Container components = null;
and

protected override void Dispose( bool disposing )<br />
{<br />
  if( disposing )<br />
  {<br />
    if(components != null)<br />
    {<br />
      components.Dispose();<br />
    }<br />
  }<br />
  base.Dispose( disposing );<br />
}

But there will be no further reference to the use of components.

Therefore, when I dynamically create a form frmDialog(), do what I have to do, then Dispose() of the form, it fails the if(components != null) check and the components are never released. I even set the form to null (which I know I shouldn't do) but that still left the form defined. In the main form, frmDialog still exists as a defined object. In frmDialog() I add my own Dispose() calls for my classes and they show as undefined but every component of the form is still defined. I suspect that is why my memory is never released; because the form components haven't been released (showing <<undefined value="">>) the form can't release.

1) My understanding is "Don't do any maintenance within the #region Windows Form Designer generated code section so how do I get the components of the form into the variable components so they can be destroyed?
or
2) Is there a routine I can add to the Dispose() method to dispose of all the components by hand? Why would I have to do this?

Thanks.

Guffa28-Sep-05 5:22

Guffa

28-Sep-05 5:22

What has made you come to the conclusion that you have a memory leak?

dbetting wrote:
it fails the if(components != null) check and the components are never released

If the components reference is null, there are no components needing disposal. If there are components that needs disposal, they are added to the components collection in the generated code.

dbetting wrote:
I even set the form to null

You can't set the form to null. You can set a reference to the form to null, but that doesn't affect the form.

---
b { font-weight: normal; }

dbetting28-Sep-05 6:24

28-Sep-05 6:24

This particular form is opened from several places within the program. It is used to review information about existing orders in the system. Every time it opens, the executable grows by about 3MB. After a couple of hours, the user session is at hundreds of MB.

Guffa wrote:
If the components reference is null, there are no components needing disposal. If there are components that needs disposal, they are added to the components collection in the generated code.
This is what has me confused. No place in the form code is components referenced.

Stepping through Dispose() of the form, when on the last brace, all the objects I have created are now showing undefined (I did have two that did not dispose properly). The only thing left at that point are the various components as defined objects. components evaluates as null and therefore the line components.Dispose(); is never reached.

using (frmContainer FrmMasterParts = new frmContainer())
{
  FrmMasterParts.SetSalesOrderInfo(SelectedOrderNumber, SelectedReferenceNumber);
  FrmMasterParts.ShowInTaskbar = false;
  FrmMasterParts.StartPosition = FormStartPosition.CenterParent;
  FrmMasterParts.ShowDialog();
}

Instantiating and calling the form is as straight forward as can be (above code). The dispose of FrmMasterParts does execute and that is what I was stepping through (shown in original message).

Guffa wrote:
You can't set the form to null. You can set a reference to the form to null, but that doesn't affect the form.
Just to see what would happen, I attempted to set FrmMasterParts to null. Unless I'm mistaken, if that did work, that would've made the memory block unreachable and it would never be released. At least that was the case in Delphi. I was just curious and surprised by the result. FrmMasterParts remained defined and unchanged.

Guffa28-Sep-05 9:03

Guffa

28-Sep-05 9:03

The Timer control for an example is a component that needs disposal. When you place a Timer control on the page, it will be added to the components collection, and will be disposed when the form is disposed.

Most controls in a form doesn't need disposal. They are fully managed, and will be collected by the garbage colector.

If you have a memory leak, it's much more likely on some object that you have created yourself, than in the code for the form.

dbetting wrote:
Just to see what would happen, I attempted to set FrmMasterParts to null. Unless I'm mistaken, if that did work, that would've made the memory block unreachable and it would never be released. At least that was the case in Delphi.

The memory management is different in .NET from Delphi or other languages using memory allocation/deallocation. The memory is not deallocated, it's collected by the garbage collector. You don't have to free the memory that is allocated. You just let the reference to the object go out of scope, and the object will be collected by the garbage collector.

The Dispose method of an object doesn't free the memory either. It's only used to dispose of unmanaged resources that the object uses. The memory used by the object itself is just left for the garbage collector to clean up.

---
b { font-weight: normal; }

Dave Kreskowiak28-Sep-05 9:36

28-Sep-05 9:36

Your problem is the .ShowDialog() call. When using ShowDialog, you MUST call .Dispose() on the Form object when you're done using it. Closing a .ShowDialog() Form does not actually close the form, as it's just hiding. The .Close() method of a Form is not called when using .ShowDialog().

using (frmContainer FrmMasterParts = new frmContainer())
{
  FrmMasterParts.SetSalesOrderInfo(SelectedOrderNumber, SelectedReferenceNumber);
  FrmMasterParts.ShowInTaskbar = false;
  FrmMasterParts.StartPosition = FormStartPosition.CenterParent;
  FrmMasterParts.ShowDialog();
  .
  .
  .
  FrmMasterParts.Dispose();
}

This is not necessary when using a Form's .Show() method.
Form.ShowDialog Method ()[^] documentation on MSDN.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

-- modified at 15:37 Wednesday 28th September, 2005

dbetting28-Sep-05 11:04

28-Sep-05 11:04

My understanding of using using() was that you don't have to worry about the dispose. That's why it was one of the first things I did when the leak showed was made evident. I replace all declarations with the using() structure.

But, to make sure, I added the line. Didn't cause a problem but didn't fix it either.

The line after the braces I had a break point. Nowhere in this. (using the Autos tab) is there any reference to FrmMasterParts. But, when the program started, I had 35MB memory in use. 15 executions of showing this form put the memory at 100MB. I just added System.GC.Collect() after the brace. Still the same result.

Dave Kreskowiak28-Sep-05 11:16

28-Sep-05 11:16

Whoops! My mistake. I misread your using line and though it wsa for a different object. using will call the .Dispose() method for you.

You've got to have another object that you're not disposing, like a Bitmap maybe?

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

dbetting28-Sep-05 12:13

28-Sep-05 12:13

Based on these conversations, I've tried a few other things. Inside FrmMasterParts, I've stepped through the creation of it and each UserControl I create inside of it. Each item I've created, I ensure there is a Dispose() or a null set to it in the Dispose() method (The enums and such didn't like that so I took them back out!). Literally, if it wasn't a form component, I added it to the Dispose(). I did this for the form and each UC.

When executing the program, upon the second and successive instantiation of FrmMasterParts, it's entire content (with the exception of the components) has everything set to undefined (as expected). This would validate that a clean copy of the form is being created with the using(). Upon display of the form, the additional memory is added. Upon the last brace of the using(), FrmMasterParts is no longer accessible but the memory has not been release. Execute GC.Collect(). Still no luck.

The last time I used a memory tool was the early '90's. Do you know of one that I can try to look at the physical memory to get an idea of what is being left out there?

An interesting note: When I minimize my 100MB program, task manager drops by about 99MB. Maximize again. I can do all kinds of stuff and memory stays small. Click the button to open this form, almost all 99MB comes back. Evaluate the content of FrmMasterParts in Autos, and it is empty as discussed above.

This is going on on my Dell laptop, a Compaq laptop as well as the development workstation and production servers so it isn't hardware related.

Thanks for your time.

Dave Kreskowiak28-Sep-05 14:30

28-Sep-05 14:30

OK. First, setting something to null isn't necessary. Once the object can't be reached any more, the GC will get around to collecting it.

What do you have that's allocating that much stuff?!
The problem you're running into is that you have unmanaged (not under the .NET memory manager control) resources being consumed and not released by one, or more, of your components on that form. There's a component that isn't releasing unmanaged memory and/or other resources, such as handles.

Oh! Task Manager is probably the worst tool you could use to track the memory usage of a managed application. Use the Performance Monitor with the .NET Framework counters or something like the CLR Profiler[^].

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

-- modified at 20:30 Wednesday 28th September, 2005

dbetting29-Sep-05 1:51

29-Sep-05 1:51

Setting didn't seem to be worth anything to me but one of my contractors insisted it was necessary. Every time he does an object.Dispose(), the next line is object = null.

The allocation of data is pulling information from the database and displaying it on screen. The screen does allow maintenance so there are several drop-down boxes on the form as well as the order data itself. I've never understood the 3MB from the beginning since it only seems like a few K of data.

To my knowledge, the only way to use unmanaged memory/code is to explicitly code it and block it into an unmanaged code block. I don't do that anywhere. If there is a way to use unmanaged memory inadvertantly, let me know what the key words are that I need to be looking for and I can focus on those.

I've downloaded CLR Profiler to see what is going on. The reason I use the Task Manager is because the boxes I'm using the application on are Citrix boxes with 4GB of memory. I have about 35 users on the system and at 9:00 I'll be sitting with about 1.5GB in use and the box is happy. As it gets to 4GB and 5GB (in the task manager), that's when things start getting flakey. So I was using that as my guide as to how the box is performing. I can look at the individual processes and those people that are 150MB to 300MB, I have them log out and log back in, memory drops back down to 2-3GB and everyone is happy again for a while.

I do thank you very much for your time.

Dave Kreskowiak29-Sep-05 11:59

29-Sep-05 11:59

dbetting wrote:
Setting didn't seem to be worth anything to me but one of my contractors insisted it was necessary. Every time he does an object.Dispose(), the next line is object = null.

How much are you paying him? Laugh | :laugh:

No, it's not necessary.

Objects that go out of scope, or can't be reached on any code path, are killed, or nulled if you wish, automatically by the Garbage Collector.

dbetting wrote:
To my knowledge, the only way to use unmanaged memory/code is to explicitly code it and block it into an unmanaged code block. I don't do that anywhere. If there is a way to use unmanaged memory inadvertantly, let me know what the key words are that I need to be looking for and I can focus on those.

There are no keyword to be looking for. The .NET Framework is essentially a large collection of classes that wraps a good deal the Win32 API. For instance, the Windows.Form class wraps a Win32 Window, which has an unmanaged window handle behind it. Calling .Dispose() on your .NET Framework Form object releases that unmanaged handle.

You're using unmanaged resources whether you explicitly do so yourself or not. An easy way to do release them is to make sure you call .Dispose() on any objects that expose this method, when your done with them.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome