[Gc] Allocation functions which don't return the true object base

Boehm, Hans hans.boehm at hp.com
Wed Jul 7 11:19:52 PDT 2004


This depends on the GC configuration.  The code below should be OK
if GC_all_interior_pointers is set, or if GC_register_displacement(OFFSET)
has been called.

If not, stack and register interior pointers should still be recognized
(to deal with frequent compiler optimizations), but interior pointers
from the heap and static data will not be.

If you have a small example for which the GC doesn't behave that way, I'd love
to see it.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Alec Orr
> Sent: Wednesday, July 07, 2004 10:35 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Allocation functions which don't return the true object
> base
> 
> 
> Folks:
> 
> I encountered functions in a 3rd party module which allocates 
> a memory 
> block, but does not return the base address of the object allocated:
> 
> #define OFFSET 0x2
> 
> void* allocMem(size_t s) {
> 	void *p = GC_MALLOC(s);
> 
> 	/* Return a pointer INSIDE the object if OFFSET > 0*/
> 	return &(p[OFFSET]); }
> 
> void freeMem(void* p) {
> 
> 	/* Translate p to the true block's beginning */
> 	p = &(p[ -OFFSET]);
> 	GC_FREE(p);
> }
> 
> int main(int argc, char** argv) {
> 	while (1) {
> 		void *p = allocMem(1024);
> 		...
> 		GC_invoke();
> 		freeMem(p);
> 	}	
> }
> 
> I reproduced a problem where for some large offsets's, or many 
> allocations with small offsets, the 6.2/6.3alpha GC will 
> report 'Attempt 
> to free invalid pointer' after full world stop allocation.  The GC 
> relies on the base pointer being present in the stack scan 
> and/or static 
> roots, correct?
> 
> Thanks for any input,
> Alec
> 
> _______________________________________________
> 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