Question

I’ve been debugging my program, because it throws Out Of Memory exceptions.
After stripping it down, it looks like a Task is holding onto a reference although it is done.
Here is my stripped down code:

public class Program {
    static void Main(string[] args) {
        var cts = new CancellationTokenSource();
        ConsumeFiles(cts.Token);
    }

    public static void ConsumeFiles(CancellationToken ct) {
        while(true) {
            var dataSource = new Queue<byte[]>();
            for(int i = 0;i < 16;i++) {
                var block = new byte[4 * 1024 * 1024];
                for(int j = 0;j < block.Length;j++) block[j] = (byte)j;
                dataSource.Enqueue(block);
            }

            var cts = new CancellationTokenSource();
            ct.Register(() => cts.Cancel()); //Remove this line => No OOM

            Task.Factory.StartNew(() => { //Remove Task => No OOM
                var b = dataSource; //Remove this line => No OOM
            }).Wait();
        }
    }
}

In my unstripped code:
The CancellationTokenSource in Main is used to cancel the whole operation.
The one in ConsumeFiles is used to cancel a suboperation, in case something went wrong in some other suboperation in ConsumeFiles.

What do I need to do so that the old instance of dataSource is properly garbage collected?
And why doesn’t it work the way it is now?

Answer 1

It’s not the task holding onto a reference

This

var cts = new CancellationTokenSource();
ct.Register(() => cts.Cancel());

is your only problem.

cts is the CancellationTokenSource that was created in your Main method. In each iteration of the loop, you are creating a new CancellationTokenSource and then registering a callback where you call Cancel on the new cts. When you register a callback, it’s passed into the token’s parent, which happens to be the token source in Main. Each time you register one, it will be added to the array, increasing it’s size as necessary.

Because the token source in main is still in scope, it’s not eligible for garbage collection, and neither is the array of callbacks that it is holding onto internally.

Here are type stats from windbg:

1- After a minute or two:

00787a68     1200        37560      Free
6d6913b8     1785        49980 System.Threading.CancellationCallbackInfo
6d64f468     1789        57248 System.Action
6d64eb28     1788        71520 System.Threading.CancellationTokenSource
6d6470cc       52    213910128 System.Byte[]
Total 6881 objects

2- A few minutes later:

00787a68     1920        56496      Free
6d6913b8     2943        82404 System.Threading.CancellationCallbackInfo
6d64f468     2946        94272 System.Action
6d64eb28     2946       117840 System.Threading.CancellationTokenSource
6d6470cc       44    180355600 System.Byte[]
Total 11064 objects

3- A few more minutes:

00787a68     3269        91514      Free
6d6913b8     4975       139300 System.Threading.CancellationCallbackInfo
6d64f468     4976       159232 System.Action
6d64eb28     4978       199120 System.Threading.CancellationTokenSource
6d6470cc       10     37748856 System.Byte[]
Total 18465 objects

Notice that each time I’ve run a stat on the heap, the number of allocated byte[] changes (because they are getting GC’d), where the number of CancellationTokenSource (the line where you new one up) types keeps increasing, along with the System.Action (the parameter you’ve passed to Register) and CancellationCallbackInfo (the internal data structure created by Register() to store the value).

From the code you’ve given, it doesn’t make any sense to create a cancellation token source at all if you want to cancel multiple threads. You can pass the token parameter (ct) into other tasks you want to cancel. Even though it’s a value type, and will be copied, the pointer to the token source remains, and you can still cancel them all with a cts.Cancel() from Main. I’m not sure if that’s what you’re trying to do, though.