[Gc] DONT_ADD_BYTE_AT_END and GC_malloc(0) (gc-7.1)

Boehm, Hans hans.boehm at hp.com
Fri May 9 17:41:12 PDT 2008

Thanks.  This indeed looks like a bug to me.  I can reproduce the problem on Itanium Linux as well.

I'm still trying to track down the cause.

Probably the least painful workaround for now is not to define DONT_ADD_BYTE_AT_END.  As far as I can tell, disabling thread-local allocation probably also works, but may lose more performance.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Shiro Kawai
> Sent: Tuesday, May 06, 2008 7:15 AM
> To: gc at napali.hpl.hp.com
> Cc: shiro at acm.org
> Subject: [Gc] DONT_ADD_BYTE_AT_END and GC_malloc(0) (gc-7.1)
> (Note for the list adminstrator: I posted this from a
> different address and it's being held for approval; please
> discard it.)
> We found that gctest of gc-7.1 may abort or enter an infinite
> loop if the gc code is compiled with -DDONT_ADD_BYTE_AT_END=1.
> Specifically, it aborts on MacOSX Leopard and it randomly
> enters infinite loop on Linux/x86 2.6.24 w/ gcc 4.1.2
> We found that the problem occurs in a collection triggered
> within this loop (tests/test.c line 1143):
>         {
>            size_t i;
>            for (i = 0; i < 10000; ++i) {
>              GC_MALLOC(0);
>              GC_FREE(GC_MALLOC(0));
>              GC_MALLOC_ATOMIC(0);
>              GC_FREE(GC_MALLOC_ATOMIC(0));
>            }
>          }
> Commenting out the two GC_FREE lines stops the abnormal behavior.
> One possible explanation I came up is that, with
> DONT_ADD_BYTE_AT_END, a pointer that points to just past an
> allocated object doesn't prevent the object to be collected,
> and since the returned pointer of
> GC_MALLOC(0) logically points to "just past" the imaginary
> zero-byte object, so it may be reclaimed between
> GC_MALLOC(0)'s return and the call of GC_FREE, causing
> already collected pointer to be passed to GC_FREE, which
> eventually does harm to gc internals.
> However, skimming at the code, it appears that GC_MALLOC(0)
> does allocate something (since GC_size_map[0] is 1).  So my
> theory above seems shaky.
> Is it just GC_malloc(0) isn't supposed to be used with
> DONT_ADD_BYTE_AT_END, or is there deeper problem with
> --shiro
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list