Re: Tracing Memory Grabbers

[William Ahern <william@...>]

On Fri, Mar 16, 2012 at 06:53:41PM +0200, Dimitris Papavasiliou wrote:
> So while we're on the subject, and since we can always ask the gc how
> much memory is allocated at a given instance but not where this memory
> is used.  Is there a way of finding out what values are still alive in
> the Lua state, and if possible, why they're still alive?  It's a
> problem I've been having on and off.  Sometimes I see that a whole
> tree of values I expected to get rid off still linger but it's not
> always trivial, tracing why they aren't collected.

There's always the venerable printf technique. Add or modify a __gc handler
to suspect userdata and tables which prints a debug message on finalization.

Or even better set a flag somewhere that is read by some regression code.
This is how I debugged some hairy Lua mutex code (using Linux eventfd),
where some sanity checks were executed on finalization.

Possibly the biggest source of leaks is use of the registry index. It's very
easy to create cycles hidden from the GC if you're not careful. With Lua 5.2
you can use ephemeron tables to alleviate this. In any event, if you're
stumped then you could do worse than a careful review of areas where
you're juggling registry index references.