C# – BindingList memory leak

bindinglistc++clrinotifypropertychangedmemory-leaks

My application uses a custom List that inherits from Bindinglist which is then bound to all the UI controls. The list is a collection of baseobjects which implements INotifyPropertyChanged. I suspected a memory leak and profiled my application using
memprofiler which confirmed that that all my lists are never disposed and that they are clinging on because they are subscribed to the propertyChanged eventhandlers of the bindinglist.

Here is the sample of my objects

public abstract class BaseObject:IDataErrorInfo,INotifyPropertyChanged,ICloneable
{
private Guid _Id = Guid.NewGuid();
public virtual Guid ID
{
    get { return this._Id; }
    set { this._Id = value;  this.OnPropertyChange(new 
                           PropertyChangedEventArgs(propertyName)); }
}

[field:NonSerialized]
public virtual event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChange(PropertyChangedEventArgs e)
{
    if (this.PropertyChanged != null) this.PropertyChanged(this, e);
}   
}

[Serializable]
public class BaseList<T> :BindingList<T>,ICloneable where T:BaseObject
{
public new void Add(T item)
{      
    <Custom code>
    base.Add(item);
     }

public new void Remove(T item)
{
    <Custom Code>
    base.Remove(item);
     }
}

Here is the allocation stack from the profiler

[Skipped frame(s)]
mscorlib!System.MulticastDelegate.CombineImpl( Delegate )
mscorlib!System.Delegate.Combine( Delegate, Delegate )
<AppName>.Data!<AppName>.Data.BaseObject.add_PropertyChanged( 
              PropertyChangedEventHandler )

[Skipped frame(s)]
System!System.ComponentModel.BindingList<T>.InsertItem( int, T )
mscorlib!System.Collections.ObjectModel.Collection<T>.Add( T )
<AppName>.Data.BaseList<T>.Add( T ) BaseList.cs
<AppName>.UI.Forms.Form1.GetData() Form1
<AppName>.UI.Forms.Form1.Initialize() Form1
<AppName>.UI.Forms.Form1.RunAsyncComplete() Form1

Can someone help me in getting the lists disposed.

Thanks all

Henk, you were right. The problem was not with the code I mentioned, instead I have narrowed it down to delegates which are preventing my form from being disposed. I am working on a sample to replicate the problem which I will upload to the site. Thanks

Best Solution

I don't believe the problem is in the code shown here, the event in BaseObject only causes outgoing references (to the subscribers). It gets a bit iffy with the hiding of Add/Remove and the BaseList class. Could it be that the < Custom Code> interferes with subscribing/unsubscribing to the PropertyChanged event?

And is where T:BaseList a typo (I would expect baseObject here) or is there another class involved?

On a side note, I am a bit puzzled by the 'virtual' in

public virtual event PropertyChangedEventHandler PropertyChanged;

I am not sure if you have a purpose for that, I think it should go.

And the BaseBusinessList should probably Implement IRaiseItemChangedEvents

1

Understand the operator basics. The C++ operator new allocates heap memory. The delete operator frees heap memory. For every new, you should use a delete so that you free the same memory you allocated:

char* str = new char [30]; // Allocate 30 bytes to house a string.

delete [] str; // Clear those 30 bytes and make str point nowhere.

2

Reallocate memory only if you've deleted. In the code below, str acquires a new address with the second allocation. The first address is lost irretrievably, and so are the 30 bytes that it pointed to. Now they're impossible to free, and you have a memory leak:

char* str = new char [30]; // Give str a memory address.

// delete [] str; // Remove the first comment marking in this line to correct.

str = new char [60]; /* Give str another memory address with
                                                    the first one gone forever.*/

delete [] str; // This deletes the 60 bytes, not just the first 30.

3

Watch those pointer assignments. Every dynamic variable (allocated memory on the heap) needs to be associated with a pointer. When a dynamic variable becomes disassociated from its pointer(s), it becomes impossible to erase. Again, this results in a memory leak:

char* str1 = new char [30];

char* str2 = new char [40];

strcpy(str1, "Memory leak");

str2 = str1; // Bad! Now the 40 bytes are impossible to free.

delete [] str2; // This deletes the 30 bytes.

delete [] str1; // Possible access violation. What a disaster!

4

Be careful with local pointers. A pointer you declare in a function is allocated on the stack, but the dynamic variable it points to is allocated on the heap. If you don't delete it, it will persist after the program exits from the function:

void Leak(int x){

char* p = new char [x];

// delete [] p; // Remove the first comment marking to correct.

}

5

Pay attention to the square braces after "delete." Use delete by itself to free a single object. Use delete [] with square brackets to free a heap array. Don't do something like this:

char* one = new char;

delete [] one; // Wrong

char* many = new char [30];

delete many; // Wrong!

6

If the leak yet allowed - I'm usually seeking it with deleaker (check it here: http://deleaker.com).

Best Solution

Related Solutions

.net – Anatothe of a “Memory Leak”

C++ – How to find memory leak in a C++ code/project

1

2

3

4

5

6

Related Question