Re[2]: [Gc] Segfault in GC_mark_from

Ivan Maidanski ivmai at mail.ru
Wed Oct 22 15:40:05 PDT 2008


Hi!

A week ago I wrote:
> At present I'm having SEGV in GC_is_mapped() which is called indirectly from GC_register_finalizer (thru GC_allocobj() and GC_finalize()). GC is compiled under FreeBSD with -DALL_INTERIOR_POINTERS -DNO_EXECUTE_PERMISSION -DLARGE_CONFIG -DUSE_MMAP -DUSE_MUNMAP -DGC_THREADS -DTHREAD_LOCAL_ALLOC [-DGC_ASSERTIONS].
> ...

Well, it was an error in my app - I passed statically allocated objects to GC_GENERAL_REGISTER_DISAPPEARING_LINK(). Now I've added a runtime check (GC_base(obj) != NULL) to see if it's safe to call GC_GENERAL_REGISTER_DISAPPEARING_LINK() for a given object or not (in the latter case, just does nothing since statically allocated objects are never de-allocated). My app now works ok...

But I've learnt the following from this case:
- GC_REGISTER_FINALIZER_NO_ORDER() works ok with statically allocated objects (just do nothing) and it's documented correctly (as "obj SHOULD be an object allocated by GC_malloc family");
- GC_GENERAL_REGISTER_DISAPPEARING_LINK() (regardless of GC_DEBUG) silently accepts everything and it's, again, documented correctly (the same as above but using the word "MUST"), and the problems of passing an incorrect argument to it arise only during GC (SEGV is generated).

So, I think, GC_general_register_disappearing_link() should be changed either:
- by adding an assertion for obj argument (HDR(obj) != NULL); or
- by doing the same as in GC_register_finalizer_inner() ("if (hhdr == NULL) return 0").

Bye.



More information about the Gc mailing list