DevForce 2010: Potential memory leak

Potential memory leak

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=2499
Printed Date: 29-Jul-2026 at 4:53pm

Topic: Potential memory leak

Posted By: midnit
Subject: Potential memory leak
Date Posted: 10-Feb-2011 at 6:19am

I have been working with Telerik for some time trying to track down what I figured was a leak in their controls but it may not be. I am passing this info on so please look and see if this is relevant to your product also as right now I see no way for me to correct the issue. I am not using their RadDomainDataSource. Any idea's?

Thanks for looking in to this.

From: Telerik Admin
Date: 2/10/2011 9:01:45 AM

Hi Robert,

Indeed we found an issue with INotifyDataErrorInfo.ErrorsChanged event handlers and we fixed with our latest internal build. Be aware that we made this fix only for our own controls RadDomainDataSource + RadGridView, since we found that memory leak is caused by DomainContext.EntitySet collection which does not clean its references. I have no idea if this fix will work with IdeaBlade's DevForce, but the idea is to clear EntitySet on refresh of the items source.
Let me know if there is something unclear.

Greetings,
Nedyalko Nikolov
the Telerik team

Let us know about your Windows Phone 7 application built with RadControls and we will help you promote it.

From: Tyree
Date: 2/10/2011 8:49:28 AM

I am unable to find anything additional that is holding onto things. We are also seeing memory increases every time we sort on these effected pages. I am leaning toward thinking it has something to do with Entities that have multiple cross relationships as in: A links to B and C, B links to A and C, C links to A and B.

Our grid is bound through the ItemsSource to a CollectionViewSource.View.

I am seeing a lot of (this as EntityWrapper)._errorsChangedHandler that seems to still be connected to things when it seemingly shouldn't. We are using IdeaBlades DevForce.

I am still looking...

Replies:

Posted By: DenisK
Date Posted: 10-Feb-2011 at 5:01pm

Hi midnit;

We checked into this and did a test creating 100,000 entities with errors. The resulting difference between memory at the start and at the end of the operation was around 5000 bytes, which is normal.

[TestMethod]

public void MemoryCheckWithErrorsChangedHandler() {

var mgr = new DomainModelEntityManager();

MemoryCheckCore(mgr);

long memStart = GC.GetTotalMemory(true);

for (int i = 0; i < 10; i++) {

MemoryCheckCore(mgr);

}

mgr = null;

long memEnd = GC.GetTotalMemory(true);

long diff = memEnd - memStart;

Assert.IsTrue(diff < 10000);

Console.WriteLine("diff = " + diff);

}

private void MemoryCheckCore(DomainModelEntityManager mgr) {

var employees = CreateTestEmployees(mgr);

foreach (var emp in employees) {

var indei = (INotifyDataErrorInfo)emp;

indei.ErrorsChanged += indei_ErrorsChanged;

GenerateErrors(emp);

Assert.IsTrue(emp.EntityAspect.ValidationErrors.Count > 0);

}

//This does the same thing as mgr.Clear()

//foreach (var emp in employees) {

// var indei = (INotifyDataErrorInfo)emp;

// indei.ErrorsChanged -= indei_ErrorsChanged;

// indei = null;

// emp.EntityAspect.RemoveFromManager();

//}

employees = null;

mgr.Clear();

}

private List<Employee> CreateTestEmployees(DomainModelEntityManager mgr) {

for (int i = 0; i < 10000; i++) {

//var emp = mgr.CreateEntity<Employee>();

var emp = new Employee();

emp.Id = -(i + 100);

//emp.EntityAspect.AddToManager();

mgr.AddEntity(emp);

}

return mgr.Employees.With(QueryStrategy.CacheOnly).ToList();

}

private void GenerateErrors(Employee emp) {

emp.FirstName = null;

emp.LastName = null;

}

void indei_ErrorsChanged(object sender, DataErrorsChangedEventArgs e) {

var propName = e.PropertyName;

}

Posted By: midnit
Date Posted: 11-Feb-2011 at 4:35am

I didn't give enough info, my apologies.

It is not related to having, or not having errors. The event handler is making, in some cases, silverlight controls leak. I have not been able to identify the exact circumstances but I am seeing in several cases where there is a combobox in an edittemplate in a datagrid and when the cell goes into edit mode that combobox is created but when leaving edit mode the combobox sits in memory and is tied to that _errorsChangedHandler. Then if you go back into edit mode another is created, over and over.

I am guessing here but it appears that if I use a List<MyEntity> where the MyEntity has no circular references that the combobox will be destroyed, but if I use an Entity A that links B and C, and B links to A and C, and C links to A and B then the combobox gets left in memory.

I have a work-around that when it leaves edit mode if I reset the ItemsSource binding to an empty binding the combobox will be destroyed. Unfortunately that means I have to handle each type of control that exhibits this behavior.

Posted By: midnit
Date Posted: 11-Feb-2011 at 4:51am

Though this shows RadComboBox I have tried microsofts with the same result. This is the retention graph of 1 of the 5 comboboxes after putting the same cell into edit mode 5 times.

Posted By: DenisK
Date Posted: 11-Feb-2011 at 9:52am

Hi midnit;

Thanks for the additional info. Let me check into this and get back to you.

Posted By: WardBell
Date Posted: 11-Feb-2011 at 1:45pm

When you wrote "where there is a combobox in an edittemplate in a datagrid " alarm bells went off for me. There is a known memory leak when the data template is defined inline, rather than as a resource. Microsoft has been trying to patch the problem but hasn't completely succeeded. Maybe next release. I suggest you move your template into a resource (can be a resource of the UserControl) and see if that helps.

You wrote "It is not related to having, or not having errors. The event handler is making, in some cases, silverlight controls leak." What DevForce event are you referring to? I don't see it in your account.

It is a hopeful sign that you get the same effect with MS controls. Maybe - after you've first tried to resolve by moving the template to a resource - if the problem persists - you can make a small test case for us.

Until then, we are at a loss to help as we don't know how to repro.