[Gc] Troubles with a custom mark procedure
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.
> -----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
> 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?
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc