[gclist] BDW collector leaking objects?

[Boehm, Hans]

This all sounds like expected behavior.  The best you can normally expect
from a conservative collector is that it will reclaim all but a bounded
amount of memory.  (I have a forthcoming POPL paper that discusses in a lot
more detail when this expectation is and isn't justified, and how you can
test whether it is.  See
http://www.hpl.hp.com/techreports/2001/HPL-2001-251.html for a slightly
earlier tech report version.)

Note that failing to reclaim a bounded number of objects (e.g. 1 or 2) isn't
a problem for long running applications.  That typically just means that the
collector is reclaiming some objects late, i.e. when the location holding a
pointer to them is reused.  Unbounded leaks are the issue (e.g. failing to
reclaim a few objects per second).  You should really run the test in a loop
and verify that the numbers don't keep growing over time.  (The above paper
suggests an additional more elaborate test.)

Even with a type accurate (non-conservative) collector, you can't expect
that all objects will have been deallocated and/or finalized by program
exit.  Objects that are still referenced at the end of the program won't be
reclaimed, since the GC has no way to tell they're no longer needed.  (Even
in the absence of a garbage collector, I don't think you should expect all
objects to be deallocated before program exit, at least not if you want your
program to perform well.  But that's a different discussion.)

In the case of a conservative collector, even if there are no real
references left, as in this case, the collector may also retain some objects
due to misidentified pointers or, more likely, since there are still
pointers to some objects in the registers and on the stack, and it can't
tell whether or not those can still be used.

Hans

> -----Original Message-----
> From: shofmann@mindspring.com [mailto:shofmann@mindspring.com]
> Sent: Wednesday, January 09, 2002 1:06 PM
> To: gclist@iecc.com
> Subject: [gclist] BDW collector leaking objects?
> 
> 
> I've been trying to use the Boehms-Detmer-Weiser (BDW) 
> collector in a C++
> application under Windows 2000 that's also using MFC, and 
> I've noticed that MFC
> has been reporting leaks in the objects derived from 
> gc_cleanup. Further
> investigation managed to duplicate the problems in a slightly 
> modified version
> of test_cpp. I'm using version 6.0 of the collector, downloaded from
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc.tar.
> gz, and built
> using MS Visual Studio 6.0 (+ service pack 5) and the 
> NT_MAKEFILE makefile.
> 
> The problem appears to be that one (sometimes more than one) 
> object is not
> being freed by the collector. I noticed that test_cpp was not 
> comparing
> nFreed directly to nAllocated, but rather was comparing it to
> 0.8 * nAllocated. Why is this? When I modified the test to 
> remove the 0.8
> multiplier, I noticed that not all objects allocated were being freed:
> 
> (output from a modified test_cpp; I added these lines just 
> before the last
> call to GC_printf0():
> 
>         GC_printf2( "C::nAllocated = %d C::nFreed = %d\r\n", 
> C::nAllocated,
> C::nFreed );
>         GC_printf2( "D::nAllocated = %d D::nFreed = %d\r\n", 
> D::nAllocated,
> D::nFreed );
>         GC_printf2( "F::nAllocated = %d F::nFreed = %d\r\n", 
> F::nAllocated,
> F::nFreed );
> )
> 
> Starting iteration 1
> Starting iteration 2
> Starting iteration 3
> Starting iteration 4
> Starting iteration 5
> Starting iteration 6
> Starting iteration 7
> Starting iteration 8
> Starting iteration 9
> Starting iteration 10
> C::nAllocated = 140000 C::nFreed = 139986
> D::nAllocated = 10000 D::nFreed = 9999
> F::nAllocated = 10000 F::nFreed = 9999
> 
> Adding a call to GC_gcollect() immediately before the above 
> GC_printf2() calls
> didn't affect the nFreed counts. As far as I can tell, in the 
> test_cpp program
> at that point there should be no valid references to any 
> objects of types C, D,
> or F.
> 
> I'd like to use the BDW collector in an application that must 
> have uptimes
> measured in days, so any leaks are unacceptable (not to 
> mention that our QA
> department will fail any software that prints out a leak 
> report upon exit). Has
> anyone else seen this behavior? Am I just being naive in my 
> interpretation of
> the test results? Thanks,
> 
> scott
> 
> -- 
> J. Scott Hofmann                      http://cougar.kniggets.org
> mailto:shofmann@mindspring.com
>