how to use GC as a leak detector? i.e. get some help info from GC?

nobody no at
Sun May 24 17:49:14 PDT 2009

> One thing you could try is disabling the GC (this really just disables automatic
> running of the collector) and run it manually at points that you know make sense.
>  For example, you could just insert a GC.collect() statement at the end of every
> run of your main loop.
> Another thing to try is avoiding appending to arrays.  If you know the length in
> advance, you can get pretty good speedups by pre-allocating the array instead of
> appending using the ~= operator.
> You can safely delete specific objects manually even when the GC is enabled.  For
> very large objects with trivial lifetimes, this is probably worth doing.  First of
> all, the GC will run less frequently.  Secondly, D's GC is partially conservative,
> meaning that occasionally memory will not be freed when it should be.  The
> probability of this happening is proportional to the size of the memory block.

I have tried all these: with GC enabled only periodically runs in the main loop,
however the memory still grows faster than I expected when I feed more data into
the program. Then I manually delete some specific objects. However the program
start to fail randomly.

Has anyone experienced similar issues: i.e. with GC on, you defined you own dtor
for certain class, and called delete manually on certain objects.

The program fails at random stages, with some stack trace showing some GC calls like:

 0x0821977a in _D2gc3gcx3Gcx16fullcollectshellMFZk ()

I suspected the GC is buggy when mixed with manual deletes.

More information about the Digitalmars-d mailing list