Re: [Gnash-dev] GC: status report & call for test

[Eric Hughes]

At 06:09 PM 7/6/2007, John Gilmore wrote:
> > This is more a problem as long as both GC and RC implementations are
> > intrusive. If we store intrusive_ptr in a class member, and the
> > instance pointed-to is destroied by the GC, a segfault would happen
> > when the intrusive_ptr destructor is is invoked.
>
> I don't understand this part.  By definition, we'd never free
> something that has an active pointer to it -- either in RC or GC
> models.  So how could we ever get a segfault from referencing
> such a pointer?

From the intrusive_ptr documentation:
>         The intrusive_ptr class template stores a pointer to an object 
> with an embedded reference count.

When you invoke an intrusive_ptr destruction, its precondition is that the 
object exists, because it decrements a reference count that exists within 
the pointed-to object.  Now suppose there had been some object that was 
already destroyed by another mechanism (GC in the example above) and there 
yet remains an intrusive_ptr to it.  When that intrusive_ptr goes out of 
scope, its destructor is called, which then tries to decrement a no-longer 
existent object.  At best, you get a segfault if the address has left its 
process's memory space.  At worst, you get a decrement on some random piece 
of memory.

The point he's making is that you can't mix GC and intrusive_ptr semantics 
between pointers referencing any given class.  Once you put some object 
under GC control, all references to it must also be under GC, because 
otherwise you end up with the above misbehavior.

Eric