how to use GC as a leak detector? i.e. get some help info from GC?
dsimcha at yahoo.com
Sun May 24 18:15:16 PDT 2009
== 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
> 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?
Also, please file a bug report, especially if you can create a concise,
reproducible test case.
More information about the Digitalmars-d