[Gc] double allocate
hans.boehm at hp.com
Tue Nov 14 14:56:04 PST 2006
> -----Original Message-----
> From: Bruce Hoult
> Sent: Tuesday, November 14, 2006 2:10 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] double allocate
> I'm in the process of tracking down a problem where
> GC_malloc() is returning the same memory block from sucessive
> calls. I'm not sure yet whether we've done something wrong
> (perhaps a memory stomper?) or whether it's an obscure bug in
> the GC, but while I'm tracking things down I thought perhaps
> someone might have an idea.
> Originally the problem was in fairly widely separated code,
> but we've now reduced it to specially inserted code that is
> run some time into the execution fo the program and does...
> void *p = GC_malloc(16);
> void *q = GC_malloc(16);
> ... in adjacent lines of code and p and q both get the same value.
> What I've tracked down so far is that when p is allocated it
> gets the last item in the 16 byte object freelist. The
> freelist is correctly set to NULL. The next call to
> GC_malloc() finds the freelist empty, gets the next
> partially-full block of 16 byte objects from the list created
> by the last GC and scans its mark bits to create a new free
> list. The first object on the new free list is .. ta da ..
> the same object allocated by the previous call to
> GC_malloc()! i.e. the object pointed to by p is in the block
> that is reclaimed next.
Definitely not good.
> So ... is it supposed to be possible to have a block not yet
> be scanned after the last GC, but also have objects from it
> be on an object free list? If this is not normal, could it
> be caused by GC_free()?
Not at the end of a collection. GC_finish_collection() calls
GC_start_reclaim(). Its first action is to clear both free lists and
lists of blocks waiting to be reclaimed.
In the absence of a client bug, GC_free shouldn't be able to provoke
that situation either. If GC_free() is called after the block is
reclaimed, we're fine. If it's called before the block has been
reclaimed, it should only be callable on a block that was marked at the
last GC, and hence won't be touched when the block is later reclaimed.
Thus it certainly shouldn't end up on the free list as part of the
> That certainly seems like a bad situation because any objects
> newly allocated from it won't have their mark bit set when it
> is scanned.
> I'll continue trying to track down how this is happening, but
> any advice is much appreciated.
If this is reproducible, conditional breakpoints on GC_free(offending
object) and GC_reclaim_small_nonempty_block(offending block) might point
at something useful.
It might also be worth checking that the list of reclaimable blocks for
that size doesn't have a cycle, and seeing how long it's been since the
last collection (GC_arrays._words_allocd vs.
Presumably, you are using 6.8?
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc