Debugging a Memory Leak

[Steven Schveighoffer via Digitalmars-d-learn]

On 11/17/14 11:41 PM, Maxime Chevalier-Boisvert wrote:
>> GC problems are *nasty*. My advice is to run the simplest program you
>> can think of that still exhibits the problem, and then put in printf
>> debugging everywhere to see where it breaks down.
>>
>> Not sure if this is useful.
>
> Unfortunately, the program doesn't break or crash. It just keeps
> allocating memory that doesn't get freed. There must be some false
> reference somewhere. I'm not sure how I can printf debug my way out of
> that.

By "break down", I mean it does what you don't want :)

You will need to instrument the GC and/or druntime.

Note, if there is a false pointer, it's likely stack based, and likely 
there is not very many of them.

But you have NO_INTERIOR set. This means the false pointer MUST point at 
the beginning of the block in order to keep it alive.

As I said, these are tricky issues. It would not be easy to determine.

One thing you can try -- allocate the block as a class, with a 
finalizer. This gives you the ability to sense when/if a block is 
finalized. That can help you determine the point at which your program 
starts to misbehave.

-Steve