[Gc] Troubles with a custom mark procedure

Boehm, Hans hans.boehm at hp.com
Fri May 26 14:40:20 PDT 2006


Particularly in a multithreaded environment, mark procedures need to be rather robust.  In particular, they may be invoked on free-list elements.  In a multithreaded environment, they may also be invoked on partially constructed objects.

(If a mark procedure is invoked on a free list element, the mark bit will subsequently be cleared again.  There is some argument that for kinds with user-defined mark procedures, we should explicitly set the free-list mark bits ahead of time, to keep this from happening.  I don't immediately remember a reason this wouldn't work, though it doesn't suffice if GC_malloc_many() is used.  But the partially constructed object issue is generally going to be the harder one to deal with anyway.)

Thus I think there are at least three possible problems here:

1) The mark procedure is not defensive enough and gets confused by a free list element.  (These should be entirely zero, except possibly for the first word.)  Or it gets confused by a partially constructed object.  These may appear to be platform-specific problems due to timing differences.

2) The collector really does invoke it on a bad object.  Try printing *GC_find_header(offending_object) from the debugger.  It should at least indicate the right kind, no mater what's in the object.  And GC_base(offending_object) should be offending_object

3) There's some other bug in your code.

The _inner variants assume you already hold the allocation lock.  You probably wouldn't use them.

Hans



> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ludovic Courtès
> Sent: Friday, May 26, 2006 9:05 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Troubles with a custom mark procedure
> 
> Hello,
> 
> In my program, I use an object "kind" that has a custom mark 
> procedure (using `GC_new_kind ()', `GC_new_proc ()', etc.).
> 
> Basically, it all works well on IA32 and PPC, but on SPARC64, 
> the mark procedure is soon passed the address of an object 
> that was never allocated for this kind (I added a `printf' 
> call right after the `GC_generic_malloc ()' call for this 
> kind, and one at the beginning of the mark procedure).  At 
> first sight, the faulty address is not even a pointer within 
> an object of this kind.
> 
> I failed to reproduce this problem with a simple example, 
> which confirms that it's certainly my fault.  Anyway, does 
> anyone have hints as to what might be failing?
> 
> Also, in `gc_mark.h' what's the different between the regular 
> functions and their `_inner' variant?
> 
> Thanks,
> Ludovic.
> 
> _______________________________________________
> 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