Disposed Instance

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.
Post Reply
gn_ctax
Posts: 2
Joined: Tue Nov 13, 2007 5:55 pm

Disposed Instance

Post by gn_ctax » Tue Nov 13, 2007 6:55 pm

I started using .Net memory Profiler a few days ago, it it seems to provide a lot of useful information about allocations and live instances and so on. One thing is unclear to me though: some objects are shown as "Disposed Instances" in Type Details, and yet they are shown as live in Types.

This is somewhat confusing. Our application is pretty complex; it uses the CAB, the CSLA and DevExpress components, and I tried hard to remove all event subscriptions and terminate WorkItems, and I thought I got objects removed (after all, they are marked as "Disposed Instances"). And yet I can still see these objects holding references to other objects. So are they live or not? If if they are, why are they marked as "Disposed Instances"? Is it only because the unmanaged resources have been disposed?

Thanks.

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Tue Nov 13, 2007 7:45 pm

An instance is marked as disposed if the Dispose method of the instance has been called. Normally the instance should no longer be used after Dispose has been called, so Disposed instances are an indication that you might have a memory leak.

To find out why the instance is still live (i.e. why it has not been GCed), you should investigate the root paths of the instance. If you need help interpreting a root path, you can post it here and I will try to help.
Best regards,

Andreas Suurkuusk
SciTech Software AB

gn_ctax
Posts: 2
Joined: Tue Nov 13, 2007 5:55 pm

Post by gn_ctax » Tue Nov 13, 2007 10:51 pm

Thanks.

Here's an example of a type (Group.Services.TaxReturn.ReturnEntity). It has 3 new instances, referenced by 44 root paths. One path is below.

Code: Select all

DevExpress.XtraGrid.Views.Grid.ViewInfo	GridDataRowInfo	#269,449
System.Collections	Hashtable.bucket[]	#269,447
System.Collections	Hashtable	#269,446
DevExpress.XtraGrid.Views.Grid.ViewInfo	GridRowInfoCollection	#247,638
DevExpress.XtraGrid.Views.BandedGrid.ViewInfo	BandedGridViewInfo	#131,506
Group.Common.Controls	EtsBandedGridView	#108,502
Group.Modules.DesktopNavigator	DesktopNavWorkAreaView	#108,661
System.Windows.Forms	LayoutEventArgs	#105,701
Microsoft.Practices.CompositeUI.WinForms	DeckWorkspace	#104,608
Group.Common.Workspaces.Layouts	WorkspaceLayoutR	#101,010
Group.Modules.DesktopNavigator	DNavWorkspaceLayoutController	#101,070
Group.Modules.DesktopNavigator	ModuleController	#101,023
Group.SmartClient	ControlledWorkItem<ModuleController>	#101,021
Microsoft.Practices.CompositeUI	SimpleWorkItemActivationService	#79
System	Object[]	#7,500
System.Collections.Generic	List<object>	#7,499
Microsoft.Practices.ObjectBuilder	LifetimeContainer	#87
Microsoft.Practices.CompositeUI	WorkItem	#67
Group.Shell	ShellApplication	#5
DEX.Infrastructure.Applications	XtraFormApplication<WorkItem, ShellFormView>	Start()

Andreas Suurkuusk
Posts: 1029
Joined: Wed Mar 02, 2005 7:53 pm

Post by Andreas Suurkuusk » Wed Nov 14, 2007 10:36 pm

Without knowing which instances in the root path have been disposed, and which instances you believe should exist, its hard to pinpoint the cause of your problem.

I suggest that you investigate this root path by going down through the instances and decide whether each instance should be alive or not.

E.g. the root path shows that your ReturnEntity instance is indirectly referenced by a GridView (#108,502). Is this GridView also disposed? If it is, then the cause of the memory problem is probably further down in the path. If the GridView is not disposed, then the GridDataRowInfo should maybe no longer reference the ReturnEntity instance (since it is disposed?). Or the GridDataRowInstance should maybe have been removed from the GridRowInfoCollection.

If you have removed a control from its parent, there is a risk that it is still referenced by the parent, e.g. through the cachedLayoutEventArgs field (which the LayoutEventArgs instance (#105,701) might indicate). This will not cause a big memory leak, since the cachedLayoutEventArgs will only reference a single instance (it's not a collection), but it might be worth investigating.

I'm afraid that I was not able to provide you with much help. If you need additional help investigating this issue, I suggest that you contact us at support@scitech.se and provide us with a session file that includes the disposed instances. It will give us much more information about the problem.
Best regards,

Andreas Suurkuusk
SciTech Software AB

Post Reply

Who is online

Users browsing this forum: No registered users and 19 guests