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?
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.
SciTech Software AB
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()
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 firstname.lastname@example.org and provide us with a session file that includes the disposed instances. It will give us much more information about the problem.
SciTech Software AB
Users browsing this forum: No registered users and 19 guests