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