[Gc] a bug in v.7.1 ?
ktreichel at web.de
Mon Mar 7 11:48:53 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;
Is it possible that the value returned is below the real start of the
If yes then there is no pointer to the just alocated memory and the
collector will reclaim that chunk of memory.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20110307/b8b0f5a7/attachment.pgp
More information about the Gc