[plt-scheme] v372: Uncollectable Scheme memory (even with sandbox.ss)

At Tue, 29 Apr 2008 14:01:04 -0400, "Eric Kidd" wrote:
> Over the past several years, we've been wrestling with a memory leak
> in Halyard. This leak appears to occur in the Scheme heap, and we
> haven't been able to control it using either custodians or sandboxes.
> 
> [...]
> 
> We're pretty much at a loss here. Is there anything else we should
> try? Are there any other statistics we should take a look at?

I'll see if I can run your code enough to see what's going on.

Meanwhile, here's how I track down memory leaks:

 1. Build 3m with `--enable-backtrace'.

 2. Pick a built-in datatype to use as a kind of radioactive tracer.
    Create an instance of the datatype and reference it from the data
    that isn't being GC'ed.

    A will executor usually works well as a tracer (because they're
    rarely used otherwise). So, maybe run

          (define w (make-will-executor))

    in the sandbox.

 3. Create several instances of the thing that should be GC'ed (but
    isn't), each of which should have an associated tracer.

 4. Use `(dump-memory-stats '<....>)' to get information on why the
    tracer isn't collected.

    Example:

        (dump-memory-stats '<will-executor>)

    You should get a path from the root to each tracer, and that path
    might tell you something interesting. You may still need help
    understanding the trace, though. If an element in the trace is
    something like <#158>, that's an instance of an internal type that
    doesn't have a name; the number corresponds to an entry in
    "stypes.h".

Matthew