RE: SIGSEGV in GC_mark_from

["Boehm, Hans" <hans_boehm at hp dot com>]

> From: Jeff Sturm [mailto:jsturm@one-point.com]
> 
> On Thu, 6 Sep 2001, Boehm, Hans wrote:
> > Is the object in question perhaps part of a free list?
> 
> It's very possible.  It appears to be a cleared object with a 
> free list
> pointer.  However this link points to an uncleared object.
If you print *GC_find_header(pointer) from a debugger, you'll get the
contents of the block header for that object, including the kind, the mark
descriptor, and the object size.  If it is indeed a free list pointer, those
should all be the same for both the source and target objects.  With high
probability, the source and target would be on the same page.

Is that true for the pointer you are seeing?  It sounds like the linked to
object has a proper vtable pointer, and was thus initialized after this
object was last added to a free list?
> 
> From your explanation it follows that every heap object must 
> be minimum 2
> words.  I added the following in GC_reclaim_clear:
> 
>     assert(list == NULL || ((void **)list)[1] == NULL);
> 
> This assert didn't catch anything.  The final clue I have is that this
> linked-to object (from where the invalid descriptor is taken) is
> consistently a large non-array object instance (152 bytes) and uses a
> procedure descriptor.
> 
Do any of these objects appear near the beginning of the appropriate free
list?  GC_gcjobjfreelist is a pointer to an array of free list pointers.
The (152/4)th entry should be the right one (where 4 is the number is the
number of bytes in a word, i.e. it would be 8 on Itanium or Alpha).

I actually don't understand how this is possible, if you are really seeing a
free list link pointing to an object with a proper vtable.  The object is
cleared when it's put on the free list.  The vtable pointer is set during
allocation (with the lock held), which removes the object from the free
list.  A free list cycle might cause it, but I have no idea where that would
come from.  I don't see how premature reclammation could cause the problem. 

Hans