Print Page | Close Window

Memory leak with one-to-one associations

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=4044
Printed Date: 12-May-2026 at 9:34pm


Topic: Memory leak with one-to-one associations
Posted By: stephenmcd1
Subject: Memory leak with one-to-one associations
Date Posted: 13-Mar-2013 at 2:01pm
I've been tracing some more memory leaks and found some odd behavior of the EntityManager.UnresolvedParentMap where it would end up holding on to detached entities - leading to a memory leak in our app.  It took some narrowing down but it seems to only happen when there is a one-to-one relationship (or at least that is where we noticed it in our app and that is the only way I could reproduce it - but perhaps it happens in other cases).  To reproduce it, I started with the NorthwindIB database and added a new table called "EmployeeDetail" that is basically a one-to-one with an Employee (I guess it is technically a One-to-OneOrZero).  It looks like this:


If I just make a new employee in an entity manager and then immediately remove it, the employee remains in the UnresolvedParentMap collection even though it is now detached.  And since it's being held by the UnresolvedParentMap, it won't ever get garbage collected and we end up with a memory leak (in our case, the Entity Manager sticks around for a while so we want to be able to evict entities and have them garbage collected).

Here is some test code that demonstrates the problem.  If we pick any other entity type (without one-to-one relationships), it will run fine.  It's just this Employee example that will break:
[TestMethod]
public void TestUnresolvedParentMap()
{
    var em = new EntityManager();

    //Make a new Employee
    var e = em.CreateEntity<Employee>();
    e.EntityAspect.AddToManager();
    e.EmployeeID = 10; //Giving it an ID isn't necessary for the bug

    //Immediately remove it from the entity manager - in this case, we'd assume it 
    //  disappears forever...
    e.EntityAspect.RemoveFromManager();

    //Sanity check - it became detached and the entity manager no longer thinks it is loaded
    Assert.AreEqual(EntityState.Detached, e.EntityAspect.EntityState);
    Assert.IsFalse(em.IsEntityLoaded(e.EntityAspect.EntityKey));

    //If we break into the debugger at this point, we can see that em.UnresolvedParentMap is still 
    //   holding on to our employee even though it is detached.

    //To double check, we'll use a weak reference to hold on to the employee
    var wr = new WeakReference(e);

    //Clear out of 'strong' reference and force garbage collection to happen
    e = null;
    GC.Collect();

    //At this point, we'd expect the employee to be gone.  But it's not!
    Assert.IsFalse(wr.IsAlive);
}



Replies:
Posted By: sbelini
Date Posted: 14-Mar-2013 at 2:15pm
Hi Stephen,

I verified the unwanted behavior and filed a bug report.
I'll follow up with you once we have a fix.



Posted By: stephenmcd1
Date Posted: 25-Mar-2013 at 1:20pm
Any estimate on when a fix would be available?  It seems the problem still exists in 6.1.12...


Posted By: kimj
Date Posted: 25-Mar-2013 at 2:41pm
We weren't able to look at this for the 6.1.12 release. Barring problems, this should be included in the next maintenance release in April. Exact date is still TBD.


Posted By: myr_zero
Date Posted: 15-Apr-2013 at 5:23am
Hi

We have our application in DevForce 2012. Same problem exists there too :( This causing lot of memory leaks. Its good if fix to this is available soon.

Thanks
Manju


Posted By: kimj
Date Posted: 15-Apr-2013 at 10:22am
Manju, any bug reported in DF2010 which also affects DF2012 will be fixed in both products. We fixed the DF2010 bug in the latest release last week, and we'll fix the DF2012 bug in the next release. We don't yet have a date for this.



Print Page | Close Window