Re: [Chicken-hackers] Invalid forwarded object howto?

[Felix]

From: Jörg F. Wittenberger <address@hidden>
Subject: [Chicken-hackers] Invalid forwarded object howto?
Date: 23 May 2012 18:05:43 +0200

> Please could somebody enlighten me, what those forwarded
> objects are?  A short note on purpose and encoding should
> be enough.

When GC takes place, live objects are copied from the stack (nursery)
to the heap (minor GC), or copied from the stack + current heapspace
to the new heapspace (CHICKEN uses a semispace garbage collection
strategy). Since objects may be shared, copying it into the new
heapspace leaves a "forwarding pointer" in the old place - it replaces
the old header of the object with a pointer to the new copy, marked by
setting the topmost bit in the pointer. When the GC tracing algorithm
encounters the same object again, it can just pick out the pointer to
the forwarded object (otherwise the object would by copied twice).

When your heap is corrupted, or when you use lowlevel primitives
("C_...") or when you have buggy FFI code or when there is a bug in
the compiler then these objects with a forwarding pointer inside may
crop up: somehow references to the old heapspace are
retained. Needless to say, this is bad.

> 
> The real question would be: how can it happen, that I
> can create an invalid forwarded object - or for that matter -
> how would I avoid it?

See above. Often it is because of interaction with C code that,
for example, retains references to GC'd data without storing them
in GC root objects.

> 
> A different though related question:  I found that when
> "member" tests against a list, which turns out to be
> an invalid forwarded object when printed, it may
> segfault.

Yes, this is likely. As I said, a forwarded object indicates a corrupt
heap. This means the process is already on the way down.


cheers,
felix