Debugging memory leak.

Bill Baxter dnewsgroup at billbaxter.com
Tue Oct 9 10:24:14 PDT 2007


David Brown wrote:
> On Mon, Oct 08, 2007 at 10:23:17PM -0700, David Brown wrote:
> 
>> 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 think I found my problem.  I have something like this:
> 
>   class Foo {
>     ubyte[20] hash;
>     ...
>   }
> 
> and a _lot_ of these are alive at any given time.  The hash is a sha1 hash,
> and so tends to be evenly distributed.
> 
> It appears that heap objects only have a single flag indicating whether or
> not they have pointers, and since classes do have pointers, the GC will
> look at the "pointers" in the hash to see if they hit anything.  Build up a
> reasonable set of these and something will point to almost everything.

Hmm.  That could be what's happening to me too.  I think I might have 
some classes with a mix of pointers and floating point data.  A dynamic 
array in the class shouldn't cause a problem, right?  Just a static one?

What's the best indicator of how much memory the gc thinks is actually 
being used?  Right now I'm using
         std.gc.fullCollect();
         std.gc.GCStats stats;
         std.gc.getStats(stats);
         writefln("%s", stats.usedsize);
plus looking at the Windows task manager mem usage for the process.
The .usedsize stat seems a little suspect, though.  A simple test 
program that allocs big arrays in a loop (storing pointers to those 
arrays outside the loop) reports usedsize of zero.

--bb



More information about the Digitalmars-d mailing list