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

[Brad Roberts]

nobody wrote:
>> 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.

After enabling the gc, did you force a collection?  Just enabling it won't cause
one to occur.

Later,
Brad