Search

Memory leak in ConcurrentQueue<T> class -- dequeued enteries are still rooted by fraserofthenight

Closed
as Fixed Help for as Fixed

18
0
Sign in
 to vote
Type: Bug
ID: 552868
Opened: 4/20/2010 10:07:57 PM
Access Restriction: Public
1
Workaround(s)
8
User(s) can reproduce this bug
After a Dequeue from ConcurrentQueue<T> (in System.threading for 3.5SP1 as well as macorlib in .NEt 4.0) the array entry is not set to default(T). This causes the referenced item to remain rooted, causing a potentially serious memory leak.

The problem appears to be in the System.Collections.Concurrent.ConcurrentQueue<T>+Segment.TryRemove(out T, ref ConcurrentQueue<T>.Segment) method. This retreves the element from the array with result = this.m_array[low]; but does not execute this.m_array[low] = default(T); . The dequeued item is still in the array.

See http://stackoverflow.com/questions/2678165/net-framework-possible-memory-leaky-classes/2679315#2679315
Details (expand)

Product Language

English

Visual Studio Version

.NET Framework 4

Operating System

Windows 7

Operating System Language

English

Steps to Reproduce

1. Create a ConcurrentQueue<T> (if using a large object or something that can reach many other objects, the problem is more pronounced)
2. Enqueue some items in the queue
3. Dequeue them

Actual Results

The items are still referenced by the ConcurrentQueue<T>, and cannot be Garbage-Collected

Expected Results

The references are set to default(T), allowing garbage collection of reference types.
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey.

 

File Attachments
File Name Submitted By Submitted On File Size  
after.png fraserofthenight 4/27/2010 72 KB
before.png fraserofthenight 4/27/2010 91 KB
ConcurrentQueueMemoryLeak.zip fraserofthenight 4/27/2010 280 KB
Sign in to post a comment.
Posted by dmacattaq on 9/13/2011 at 1:12 PM
I am very disappointed to see that this was not fixed/released with Visual Studio 2010 SP1. There were updates to the .NET Framework, granted they were small, but this was known about way before SP1 was released. Is there any chance that a hotfix can be created for this?
Posted by Diego Frata on 4/5/2011 at 12:29 PM
When are the next version going to be released?
Posted by fraserofthenight on 6/3/2010 at 6:25 AM
IOW, the class is totaly useless for the next few years? Sigh...
Posted by Microsoft on 6/1/2010 at 4:32 PM
Hi Fraserofthenight,

This will be fixed in the next version of the .NET framework.
Posted by kosak on 5/27/2010 at 8:53 AM
Thank you for fixing the issue. Is the fix available for download? I'm unable to use ConcurrentQueue<T> in my program while it still has this issue.
Posted by Microsoft on 4/30/2010 at 11:32 AM
Thanks for your feedback, we have fixed this issue
Posted by fraserofthenight on 4/27/2010 at 10:54 AM
I'm not sure how much help the screenshots will be (it's a memory leak...). The example project references the System.Threading from http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx , since I don't have 4.0 installed on this computer; however the problem should repro in 4.0 with the exact same code (just change the reference in the project).
Posted by Microsoft on 4/21/2010 at 11:10 PM
Thank you for reporting this issue.
To help us better understand the scenario, could you please attach some screenshots and a zipped project file to this feedback through our site?

Thank you,
Visual Studio Product Team.
Posted by Sam Harwell on 4/20/2010 at 10:17 PM
Until this issue is resolved, ConcurrentQueue<T> is unusable in our application.
Sign in to post a workaround.
Posted by Diego Frata on 4/5/2011 at 1:47 PM
The ConcurrentQueue<T> will hold only a maximum of 31 dequeued objects in the worst case. You can reproduce this behavior by calling Enqueue 31 times and calling TryDequeue 31 times after that. If you do this one more time, the current Segment will be discarded because it was completly used.

Until a fix is issued, you should avoid creating an exagerated number of ConcurrentQueue<T> instances. For normal uses, it won't cause any perceivable increase of memory.
© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement