Memory Leak from ChildChanged Event Handler

Memory Leak from ChildChanged Event Handler

Old forum URL:

snakebyteme posted on Thursday, August 26, 2010

I am iterating through 2000 business objects using CSLA 3.8.1.

I instantiate them one at a time, call a processing function, and then advance the loop.

The memory usage just keeps incrementing.

When I run ANTS memory profiler, it gives me this:


ObjUser(this as BusinessBase)._childChangedHandlers

System.EventHandler<Core.ChildChangedEventArgs> (this as MultiCastDelegate)._invocationList


System.EventHandler<Core.ChildChangedEventArgs> (this as Delegate)._target

ObjUserDetail(this as BusinessBase)._fieldmanager


These objects have not subscribed to the ChildChanged event.

Can anyone shed some light on what I should be looking for to eliminate these event handlers from preventing garbage collection?

RockfordLhotka replied on Thursday, August 26, 2010

First, you should check the change logs for 3.8.2, 3.8.3 and 3.8.4 to see if there've been any bug fixes around parent-child relationship management over that time.

Second, you should realize that within an object graph the objects handle each other's events. In particular, a parent always handles events from its children. But that doesn't matter from a memory perspective, since that is all contained within the object graph.

What isn't clear to me from your post is whether something outside the object graph is somehow handling the events?

Third, and this is perhaps the issue, you can only use a managed backing field to reference a child object. People sometimes use a managed backing field to implement a "using" relationship - to hold a reference to a non-child object. That's bad. That'll cause all sorts of issues - including n-level undo confusion, serialization nastiness and quite possibly memory leaks due to event handlers.

But if that's the issue, that's just a bug in the business code.

snakebyteme replied on Monday, August 30, 2010

We put a business object (User) in the Custom Identity and were assigning it to each object's "User" property before we wrote it to the database.

That reference (User-->CustomIdentity-->CustomPrincipal) was preventing the object from being garbage collected.

Thanks for the direction Rocky. There is nothing more frustrating than a memory leak.

RockfordLhotka replied on Monday, August 30, 2010

I'm glad you found the issue. Memory leaks really are frustrating...

Copyright (c) Marimer LLC