[Gc] a bug in v.7.1 ?

Glauco Masotti glauco.masotti at libero.it
Mon Mar 7 11:00:25 PST 2011


I compiled the GC as a static library with GC_ASSERTIONS, GC_PRINT_VERBOSE_STATS defined, so that I got the log. Nothing 
wrong or alarming however.

I followed the steps suggested in debugging.html, in the documentation.
After GC_gc_no++; I placed a call to GC_is_marked(GC_base(problematic_object));
Where problematic_object is the object that I get overwritten.

problematic_object  = vector(5100, 24359);

where vector is taken from "Numerical Recipes in C" and is defined as:

float *vector(long nl, long nh)
  /* allocate a float vector with subscript range v[nl..nh] */
{
  float *v;
  v=(float *)malloc_atomic((size_t) ((nh-nl+1+NR_END)*sizeof(float)));
  if (!v) nrerror("allocation failure in vector()");
  return v-nl+NR_END;
}

It results that the object has been marked! Thus it's NOT about to be reclaimed right?
So the object is still alive after the collection.
Moreover it contains correct data till I get to a call to:

e = dvector(1, 999) // the double version of vector

>>> This allocation causes problematic_object to be overwritten! <<<

How is it possible that malloc_atomic returns an address which is in the range of a live object?
Perhaps, at this point, the only explanation is that the data structures used by the allocator has been messed up.
But the GC senses everything as normal, no assertion is violated and no warning is issued!
What else can I try to find out (and possibly fix) what's wrong?
I need your help in order to proceed. I am at a dead point.

--- Glauco Masotti






More information about the Gc mailing list