Re: gc.c -- possible logic error?

On Tue, 2 Oct 2007, Hugh Sasse wrote:

> All well and good, but what's bothering me is the asymmetry in the mark
> and free functions:
> 
>  8210 static void
        [...]
>  8214     while (data) {
>  8215         rb_gc_mark_frame(&data->frame);
>  8216         rb_gc_mark((VALUE)data->scope);
        [...]
>  8220         rb_gc_mark((VALUE)data->dyna_vars);
>  8221         rb_gc_mark((VALUE)data->cref);
        [...]
>  8227
>  8228 static void
>  8229 frame_free(frame)
>  8230     struct FRAME *frame;
        [...]
>  8241
>  8242 static void
>  8243 blk_free(data)
>  8244     struct BLOCK *data;
>  8245 {
>  8246     void *tmp;
>  8247
>  8248     while (data) {
>  8249         frame_free(&data->frame);
>  8250         tmp = data;
>  8251         data = data->prev;
        [...]
> So a whole load of components of data get marked by the GC, but don't
> get freed in the free function, because only the frame component
> gets that treatment.  Components var, body and cref are all pointers,
> so where do they get unmarked and freed?  I can't match /free.*cref/
> in this file (eval.c).

I experimented with this, freeing data->scope and data->dyna_vars in
eval.c and these just resulted in crashes during the build when
invoking mkmf.  So it isn't that.   I suppose that data won't get
unmarked until its contents have been freed.  I've not got to that
level of understanding yet.  So I'm not sure what more I can do to
track this down at the moment.

        Hugh