[Gc] object collected while still in use - test case

Boehm, Hans hans.boehm at hp.com
Thu Oct 18 09:59:00 PDT 2007

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Bruce Hoult
> Sent: Thursday, October 18, 2007 2:14 AM
> To: Chris Moore
> Cc: gc at napali.hpl.hp.com
> Subject: Re: [Gc] object collected while still in use - test case
> On 10/18/07, Chris Moore <christopher.ian.moore at gmail.com> wrote:
> > I recently started trying to use libgc, and pretty quickly came up 
> > against a problem where objects are being freed while still in use.
> >
> > I managed to make a relatively small test case:
> >
> >     https://dooglus.rincevent.net/random/gc.cpp (1177 bytes)
> Fairly obviously, the STL std::vector class is using malloc() 
> to allocate its memory.  You need to find a way to make it 
> use GC memory so that it is traced for pointers.

Unfortunately, the only options there are:

1) Use one of the allocators provided by the GC.

2) Do something non-portable to get the default allocator to use garbage
collected memory.

Depending on your application and platform, you may be able to do (2) by

a) Getting the STL default allocator to call malloc directly.  Some
implementations do that by default, others do not, but may provide an
option do do so.  I think that defining __USE_MALLOC consistently when
building with the GNU C++ library may still have that affect.

b) Build the GC to enable malloc interception.  This is much more robust
in some environments than others, and I would suggest a very recent GC.
I wouldn't really try it except on Linux, especially with threads.  It
is believed not to be reliable with some of the standard GNU Linux font
libraries, or dlopen use.  (The collector has an overly simplistic idea
about where thread locals are.  If you use lots of them, I wouldn't be
surprised if it broke for that reason as well.)


More information about the Gc mailing list