Click here to Skip to main content
15,918,485 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
I am working on finding memory leaks in my application.
I have a hashtable which has elements of type List<IMxCallBack> (where IMxCallBack is native interface).I found that the IMxCallback objects in each list element of hashtable are not disposed.I successfully disposed them and found that there are removed from the heap as well in the leak Dump taken on my application.
But however I found that there are Hashtable objects still on the heap, also the same number of Hashtable+bucket[] objects on heap.But I have disposed the hashtable in dispose as well.
An aaCalConnection obj is created for every click on my window(which switches to another window).Upon click for every 3 seconds the existing aaCalConnection obj is disposed and hence the hashtable as well.And again a new aaCalConnection object is created which inturn creates a new Hashtable.Please find the code below

public aaCalConnection(CONNECTIONTYPE ConnType, string Node, string Application, string Topic, aaDataSubscriptionManager Callback, bool isLocalConnection, aaAccessName accessname, aaCalConnectionManager CalMgr)
            m_CalbackCache = new Hashtable();

void AddCallbackToCache(int datasourceId, IMxCallback callback)
			//Add this callback to the queue of pending writes
			List<IMxCallback> callbackList = m_CalbackCache[datasourceId] as List<IMxCallback>;
			if (callbackList == null)
				callbackList = new List<IMxCallback>();
				m_CalbackCache[datasourceId] = callbackList;
			if (callbackList != null)

public void RemoveCallbackFromCache(int datasourceId, IMxCallback callback) 
			//Remove this callback from the queue of pending writes
			List<IMxCallback> callbackList = m_CalbackCache[datasourceId] as List<IMxCallback>;
			if (callbackList != null)
        		        if (callbackList.Count == 0)
	                	    m_CalbackCache[datasourceId] = null;
		                callbackList = null;

public virtual void Dispose()
			m_CalbackCache = null; 
// Disposing the IMxCallback object which is a userconnection callback object from another class
m_CalConnection.RemoveCallbackFromCache(callback.DataSourceID, callback);

Now eventhough the cleanoffs are properly done I could see hashtable and HashTable buckets objects on Heap occupying memory.Can anyone tell me why they are not Garbage collected.How should i go about resolving this leak?

BobJanova 15-Apr-11 8:40am    
Does IMxCallback implement IDisposable?
narayanagvs 15-Apr-11 10:41am    
IMxcallback doesn't implement IDisposable but Userconnection call back object does.

public class aaUserConnectionCallback : IMxCallback, IDisposable
IMxcallback is created in the below manner.

if ((object)userConnectionCallback == null &&
(l_subscriptionClient.m_isIntouchTag || l_subscriptionClient.DataSourceType == aaDataSourceType.AutomationObjectAttribute))
userConnectionCallback = new aaUserConnectionCallback();

IMxCallback mxCallback = userConnectionCallback as IMxCallback;
BobJanova 15-Apr-11 12:25pm    
The hashtable can't know that the IMxCallback's you're putting in it are aaUserConnectionCallback's, though. Are you in charge of the IMxCallback interface? If so, extend it to include IDisposable. If not, create a new cover interface that extends both, and use that as the list type.

Because you are using a native interface, you probably have unmanaged resources that need to be cleaned up. Have a look at this link for more info:[^]

Good luck!
Share this answer
narayanagvs 15-Apr-11 9:33am    
Eventhough I am using native interface , I am disposing it.I also implemented your suggestion of calling dispose in a secured way.But my client calls dispose properly and both Managed and unmanaged resources are cleaned.
Now while debugging the code in dispose I could notice that eventhough I have cleared the hashtable.The buckets in hashtable are not cleared.I even assigned null to hashtable after clearing it but still there are hashtable and hashtable bucket objects in the heap.
E.F. Nijboer 15-Apr-11 9:59am    
Maybe this will help. It is an example of a somewhat different matter but it might be the same in essence. It could be that there are still references that prevent garbage collection.
Sergey Alexandrovich Kryukov 15-Apr-11 14:43pm    
Consider managed memory leak then. Please see my Answer.
I already saw your comment where you insist that you dispose all disposable objects.
For a record: I'm sure the bucket-based hash can be well implemented using pure CLI, with no unmanaged code.

Now, what else?

You can generate a memory leak in pure managed code. Do you have anything static in your library or even if you test application?

If not, look at anything with long life time. You can simply accumulate some references and such object and never release them. GC need totally lost references to act.
Remember, managed code memory leaks are quite possible. It's not so trivial to defined what's a leak. Basically, it only makes sense you do some cycles and come back to some state which is functionally equivalent to the previous state, but the consumed memory is more then in the first time. This is not so apparent because GC may defer reclaiming memory until more convenient later moment of time. For more clear experiment you can use System.GC to force garbage collection at some check points using System.GC.Collect, see[^].

Also, you can consider using weak references,[^].

Share this answer
Albin Abel 15-Apr-11 15:16pm    
Good points. my 5
Sergey Alexandrovich Kryukov 15-Apr-11 15:22pm    
Thank you, Albin.
Jeffrey Enzo 15-Apr-11 15:25pm    
Nice, also my 5!
Sergey Alexandrovich Kryukov 15-Apr-11 15:26pm    
Thank you, Jeffrey.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900