A while back I wrote about an issue with the ConcurrentBag-class. By chance, I came across an explanation here - and best of all, it is fixed (more or less...) in .NET4.5.
In a current project I was using the .NET-framework-class ConcurrentBag. I am quite confident that I was using this class in a context for which it was designed for: in a scenario where the same thread will both be producing and consuming data and where concurrent access is quite often to be expected.
However - there is reason to believe that ConcurrentBag causes (or at least: is likely to cause) a memory leak. A web-search gives quite a few hits where people come to (seemingly) the same conclusion - e. g. here or here or (possibly related) here. In all these discussion I have not yet seen a final and authoritative conclusion - so I am somewhat confused currently. Should it be possible that such a huge flaw goes unnoticed? Am I missing something?
Well, I hope I get around to investigate this case more thoroughly - and of course post the results here. For the time being I ended up replacing the ConcurrentBag by a simple List<>, spiced with some locking. We'll have to see if that fixes the issue.