[gclist] BDW collector leaking objects?

[Scott Hofmann]

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