[Gc] a bug in v.7.1 ?

David Spencer spencer at panix.com
Mon Mar 7 16:01:42 PST 2011


On 7 Mar 2011, at 14:00, Glauco Masotti wrote:
>
> 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;
> }

Unless NR_END is greater than nl, the behavior of the expression in  
the return statement is undefined. The result of the pointer  
subtraction (v-nl+NR_END) does not point to the same object as the  
pointer operand (v).

There is no valid pointer to the allocated object after the return.  
The object is therefore highly problematic.

The bug is in the function, not the collector.




More information about the Gc mailing list