Debugging memory leak.

[Bill Baxter]

David Brown wrote:
> 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.

I'm not sure how to do it either, but we definitely could use some 
debugging tools to help figure out what memory is hanging around and who 
the GC thinks is referring to it.

I think I may have a memory leak too, since when I run my program in a 
loop, things get slower and slower.

--bb