Debugging memory leak.

[David Brown]

On Mon, Oct 08, 2007 at 09:04:27AM -0700, David Brown wrote:

> I've been developing an application on x86_64 (dgcc) without any problems.
> Yesterday, I tried building it on x86 to discover that it has a memory leak
> on that platform.  The leak is rather significant, and the program quickly
> exhausts memory and is killed.
>
> Any suggestions from the list on how to debug/fix this?

Thanks to the posts and suggestions on fixing zlib.  I've tried patching
zlib to use ubyte[] instead of void[].  Unfortunately, it doesn't really
fix things.

I seem to have something else in my program that is making lots of stray
pointers for the GC to follow.  My program consistently leaks memory until
it is killed by running out of address space (or I kill it because it is
trying to swap my machine to death).

I can make it much better by manually 'deleting' some large buffers, but
there shouldn't be any references to them, so it is only something invalid
pointing to them that is keeping them.  That it happens much more slowly on
x86_64 also suggests this, since fewer random pointers would point to a
valid block.

Any ideas on how to find this?  For a C program, I would use valgrind, but
I'm not sure what to do here.

There was some mention of a problem with the flags changing when resizing
an array.  Might this be a possible problem?

My other thought is to allocate something large, with std.c.stdlib.malloc
and put some special checks in the GC to trace anything down that it thinks
is pointing in to my, I guess I'd call it a memory honey pot.  It might be
some work to track these down, but it's a possibility.

Thanks,
David