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

Hans Boehm Hans.Boehm at hp.com
Sun May 11 22:13:53 PDT 2008


Here's a patch that I think fixes the problem.  The problem is that there 
are thread-local free lists for size zero objects, but in a couple of 
places the code forgot about that.

Hans

--- thread_local_alloc.c.orig	Sun May 11 12:45:37 2008
+++ thread_local_alloc.c	Sun May 11 12:49:10 2008
@@ -87,7 +87,7 @@
      if (0 != GC_setspecific(GC_thread_key, p)) {
  	ABORT("Failed to set thread specific allocation pointers");
      }
-    for (i = 1; i < TINY_FREELISTS; ++i) {
+    for (i = 0; i < TINY_FREELISTS; ++i) {
  	p -> ptrfree_freelists[i] = (void *)1;
  	p -> normal_freelists[i] = (void *)1;
  #	ifdef GC_GCJ_SUPPORT
@@ -291,7 +291,7 @@
      ptr_t q;
      int j;

-    for (j = 1; j < TINY_FREELISTS; ++j) {
+    for (j = 0; j < TINY_FREELISTS; ++j) {
        q = p -> ptrfree_freelists[j];
        if ((word)q > HBLKSIZE) GC_set_fl_marks(q);
        q = p -> normal_freelists[j];

On Tue, 6 May 2008, Shiro Kawai wrote:

> (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 DONT_ADD_BYTE_AT_END?
>
> --shiro
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>


More information about the Gc mailing list