Memory Leak - 3.8.2?

Memory Leak - 3.8.2?

Old forum URL:

jamie.clayton posted on Monday, June 07, 2010


I've got a CSLA data loading application that generates a OutOfMemory Exception when I load 64,000+ children into a ChildList. I ran Red-gate memory profile 5.2 over the solution, and found some unexpected results when reviewing the memory usage. I found a series of CSLA based memory usage that didn't make sense to me. See screenshot below.

I can understand all the increases that match the volume of records in the child object, but the first few entries concern me. Does this indicate a memory leak in some of the CSLA namespaces?

Can anyone with Memory profiling experience shed some light on these results?

ejames replied on Wednesday, June 09, 2010

I ran into this problem recently.  Here is my solution.

Upon construction, the Csla.Security.RoleForProperty class instantiates 6 List<string> objects for each of its properties.  This happens even if you do not use Authorisation rules.

I changed the Csla.Secuirty.RoleForProperty  and my memory leaks went away (and performance improved).

Here's what I changed:


You must change all the properties to lazy initialise the List<string> object.

Hope this works for you as it did for me.

RockfordLhotka replied on Wednesday, June 09, 2010

That seems like a good optimization, I'll add that to the to-do list.

I don't know that a List<string> can be characterized as a memory leak though - just a waste if you don't use them Smile

Leak implies some reference scheme by which the memory can't be reclaimed - which typically comes from a static field or object maintaining a reference to non-static objects (either directly or by exposing a static event).

bniemyjski replied on Monday, June 14, 2010


We will be making this change in the CSLA 3.8.x branch. Here is a link to the bug.


-Blake Niemyjski

bniemyjski replied on Wednesday, July 14, 2010


The fix has been checked in.


-Blake Niemyjski

Copyright (c) Marimer LLC