[Mono-list] Memory leak

[Jon Harrop]

On Friday 06 February 2009 10:02:25 Alan McGovern wrote:
> Hi guys,
>
> Someone emailed me a C# version of the 'leaking' program (leak.cs). As was
> stated by Rodrigo, this bug is caused by stack slots not being
> overrwritten. I've attached a non leaking version (recurse.cs) which adds
> some recursion so the stack slots are overrwritten. This version exhibits
> no leak and will run forever.

The essence of your workaround seems to be in passing the queue around as a 
superfluous function argument. Your use of recursion is actually a red 
herring. You can see this by factoring out the initialization code into a 
separation function in the code below, which also works around the bug but 
without having to introduce unnecessary recursion.

> Jon, so if your application is 'leaking' on mono, it's not due to the list
> implementation,

Are you saying that these bugs in Mono afflict a wider class of data 
structures than queues, graphs, lazy lists and closures? Do you have other 
code samples that also leak indefinitely?

> unless of course your application performs all it's operations in the same
> stack slot.  

Your description is vague but, if my interpretation is correct, the following 
is another trivial counter example that introduces new functions "push" 
and "pop" with their own stack frames but still leaks on Mono:

using System;

class Leak {
    class Cell<A>  {
        public A content;
        public Cell<A> next;
    }

    static Cell<int[]> tail = null;

    static void push(int[] x) {
        var tail2 = tail;
        var cell = new Cell<int[]> { content = x, next = tail2.next };
        tail2.next = cell;
        tail = cell;
    }

    static void pop() {
        var tail3 = tail;
        tail3.next = tail3.next.next;
    }

    static void Main() {
        var cell = new Cell<int[]> { content = new int[0], next = null };
        cell.next = cell;
        tail = cell;
        while (true) {
            push(new[] { 1, 2, 3, 4 });
            pop();
        }
    }
}

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e