BlockingCollection holds references to its contents even after they have been removed

BlockingCollection holds references to its contents even after they have been removed by Scripticus

Closed

as Duplicate Help for as Duplicate

Type:	Bug
ID:	626251
Opened:	12/1/2010 7:59:12 AM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

The BlockingCollection object (and possibly others) has some internal structures that hold referneces to its contents. There must be some sort of cycling pool of these object because after all the contents have been removed, something in there is still holding references to the noe removed objects. This prevents them from being garbage collected. In my case, it was 50MB BitmapSource object and after adding and removing 0 or so, my app runs out of memory.

Details (expand)

.NET Framework 4

Reliability

1) Create a BlockingCollection
2) Add 10 (larger is better to see the problem) objects to the collcetion using the Add method
3) Remove all 10 objects using the Take method.
4) Do not allow the BlockingCollection itself to be collected, keep a reference to it so it stays alive.
5) Use a memory profiler to verify that the 10 objects are still in RAM and have not been collected.

English

Windows 7

English

The objects removed from the BlockingCollection are never garbage collected (ulness the BlockingCollection itself is garbage collected).

The objects removed from the BlockingCollection should be garbage collected shortly after being removed from the collection, even if the collection itself remains active.

File Name	Submitted By	Submitted On	File Size
BlockingCollectionMemoryLeak.zip	Scripticus	12/2/2010	59 KB

Posted by Microsoft on 12/14/2010 at 11:53 AM

Hi Moorster2-

Thanks for taking the time to report this issue! The problem was in ConcurrentQueue, which is used by default in BlockingCollection (unless you specify an alternate IProducerConsumerCollection when you construct the BlockingCollection). The bug was that ConcurrentQueue would maintain references to up to the last 32 elements in the queue, even if those elements were removed, and thus that behavior translates to BlockingCollection as well. The problem has already been fixed for a future release.

Best,
Stephen Toub
Parallel Computing Platform

Posted by Microsoft on 12/5/2010 at 9:29 PM

Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Posted by Scripticus on 12/2/2010 at 7:21 AM

I just uploaded a sample project that demonstrates the problem and the workaround. It's in the zip file named BlockingCollectionMemoryLeak.zip.

Thanks!

Posted by Microsoft on 12/1/2010 at 9:53 PM

Thanks for reporting this issue. Please give us a demo project to demonstrate this issue so that we can conduct further research.

Thanks again for your efforts and we look forward to hearing from you.

Microsoft Visual Studio Connect Support Team

Posted by Microsoft on 12/1/2010 at 5:53 PM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

Posted by Scripticus on 12/1/2010 at 8:05 AM

(Sorry that should say "after adding and removing 10 or so, my app runs out of memory.")

The workaround that I used was to create a wrapper object around my BitmapSource and when I Take() one out I set the wrapper's reference to the BitmapSource to null. That way the BlockingCollection only holds references to the small wrapper and not the entire BitmapSource.