[Gc] a bug in v.7.1 ?

Glauco Masotti glauco.masotti at libero.it
Mon Mar 7 15:17:54 PST 2011

> > 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;
> > }

> Is it possible that the value returned is below the real start of the
> float vector?
> If yes then there is no pointer to the just alocated memory and the
> collector will reclaim that chunk of memory.

Thanks Klaus for the suggestion. I was thinking about this too. The case is certainly so!

However this means that the standard routines of Numerical Recipes (NR) cannot be used with the collector!!!
I think that NR algorithms are pretty widespread, so it's surprising that nobody hit this issue hitherto.
I haven't searched exhaustively all the messages in the archive, but perhaps Hans should remember if this problem has 
come out before.

I have a lot of stuff derived from NR algorithms, and I have been using it together with the GC for several years 
without having encountered problems so far.
But it's true that almost always the allocated vectors or matrices have their  starting index = 1, or sometimes = 0.
In these cases (given NR_END = 1), the returned pointer either coincides with what is returned by malloc_atomic or 
points inside that area, so this should be fine for the collector.
The allocation routines however are generalized to allow the definition of arrays with arbitrary subscript range.
As long as we use MMM this causes no problem, although it's not ANSI compliant (there is a discussion of this issue in 
the book).

However this is the first time that I defined a vector with a large initial subscript! And it turned out that the 
collector gets fooled by this.
I modified the code using a subscript range starting from 0, and . everything ran smoothly!
So this bug and a solution have been found, but I should place limitations in the allowed subscript range for NR 
allocation routines.

Given the popularity of NR code, maybe this case deserves a citation in the documentation. What do you think?

Best regards,
--- Glauco Masotti

More information about the Gc mailing list