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

[dsimcha]

== Quote from nobody (no at where.com)'s article
> > 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.

I personally have not experienced this.  Please be more specific:

D1 or D2?
If D1, Phobos or Tango?
DMD, LDC, or GDC?
Compiler version?

Also, please file a bug report, especially if you can create a concise,
reproducible test case.