instances that have been disposed but not GCed.

[antoniorb78]

Dear All.

I'm developing software with VB.NET.
When I open forms and then I close them the virtual memory doesn't released adn this is increasing each time that I open a new form.

I have made a simple software that It opens and close several forms. I close the forms with .close and .dispose but the virtual memory is increasing.

I have open a form and I have close it and I have done a snapshot, then I have open the form and close it again and i have done a snapshot again and I have compared them

The first issue is :
4 types have instances that have been disposed but not GCed.
Investigate the types below for more information.
Open_Close_Forms.Form2, System.Drawing.Graphics, Button, WindowsFont
Why? What I have done bad?

The second issue is:
Undisposed instances (release resource) (Show details) (Ignore...)
One type has instances that have been garbage collected without being properly disposed.
Investigate the type below for more information.

WindowsFont
Why?

And the third issue is:
Pinned instances (Show details) (Ignore...)
2 types have instances that are pinned in memory.
Investigate the types below for more information.

System.Object, System.Object[]


I don't know why and how to fix them. Could you tell me why?

The code

Code: Select all

Form2.Show() (When I open the form)

 Me.Close()
Me.Dispose() (When I close the form from the button)

[Andreas Suurkuusk]

When an instance is disposed, it is usually an indication that the instance should no longer be used. If such an instance exists when you collect a snapshot it can often be a sign of a memory leak. That's why the profiler reports "instances that have been disposed but not GCed".

To find out why an instance has not been GCed you need to investigate the root paths of the instance. I also recommend that you try to open an close the form multiple times, to see if there seems to be a growing memory leak, or if it's just one instance that is kept in memory. It is pretty common that instances are kept alive by a single field, and when a new instance gets created, the field is reused (e.g. something like a m_lastOpenForm field).

Undisposed instances are usually just a performance issue. If the instance is properly disposed, any unmanaged resources will be released quicker, and a costly finalization can be suppressed. Undisposed instances are pretty common in the .NET Framework, and cannot be fully avoided. I believe that the undisposed WindowsFont is caused by the .NET Framework, so there's nothing you can do about it (except ignoring the issue). If possible, make sure that all instances you create yourself are properly disposed.

There will always be pinned instances in a snapshot, but pinning too many instances can cause a performance problem. Pinned System.Object[] arrays are used by the .NET runtime when implementing static fields, so you will always have pinned object[] arrays. Unless you see a significant amount of pinned instances, you can safely ignore this issue.

[antonirob]

Dear Andreas, thanks for your reply.

In this case I only have two forms and one form open the other form and the other form is closed/disposed for a button that is implemented in the own form.

It's very strange because if I open and close this form several times the virtual memory is increased.

How can I follow the root path of the instance? I don't understand you with root path. Could you send me an example?

I try to understand the examples from the .NET Memory Profiler web page but it's from an older version.


Thanks

[Andreas Suurkuusk]

As long as an instance is reachable from any root (e.g. a static fields, a stack variable, or method argument), it cannot be garbage collected. A root path shows you how an instance is reachable from a root and provides you with information about why an instance has not been GCed. Root paths are presented in the Type/Filter details view and in the Instance details view. In the Type/Filter details view, the root path to the closest root is presented for all instances. In the Instance details view, all shortest root paths are presented for the selected instance.

The screenshot below shows a root path for an instance. The instance is prevented from being GCed by the static field ProfilerApplication.s_current. The instance is indirectly referenced by the static field through the instances #1029, #25,136, #13,633, and #3,176.

Instance root path

The same root path can also be seen in the instance graph:

Graph root path

[antoniorb]

Dear Sir:

I have executed my simple application and the virtual memory is increased every time i open a form. I have tried to show the screens but I can't upload the 5 images (in a word document) and profiler. How can I upload this kind of files to show you? I don't know read the results.

Thanks

[Andreas Suurkuusk]

How do you measure the virtual memory usage? Due to the way the garbage collector works, it's not always easy to correlate the virtual memory usage with the actual memory used by the application. You can get some more information about the virtual memory usage of the application by taking a look under the "Native memory" page. You can also get detailed unmanaged memory information by enabling the unmanaged resources trackers.

If you have some files that shows the increased virtual memory usage, you can provide them to us by uploading them to our ftp. I have e-mailed you the login information for the ftp server.