Forum: Ruby-core 1.8.6 segfault & fix

We've been seeing a number of reports of segfaults with 1.8.6 when
people upgraded from pl287 to pl369.  I, unfortunately, don't have a
simple test case that exposes the segfault, but I did have access to
some code that would dependably cause it.  I traced the source of the
segfault to gc.c.  Specifically, in run_final:

    if (BUILTIN_TYPE(obj) == T_DEFERRED && RDATA(obj)->dfree) {
        (*RDATA(obj)->dfree)(DATA_PTR(obj));
    }

By changing the if line to this:

    if (BUILTIN_TYPE(obj) == T_DEFERRED && RDATA(obj)->dfree && 
DATA_PTR(obj)) {
        (*RDATA(obj)->dfree)(DATA_PTR(obj));
    }

The segmentation faults go away.

Even considering the current lack of a simple test case that
demonstrates the segfault, does anyone have any speculation regarding
what may be the underlying reason why DATA_PTR(obj) could sometimes be
null before run_final gets called?


Thanks,

Kirk Haines

Hi,

At Sat, 4 Jul 2009 06:41:49 +0900,
Kirk Haines wrote in [ruby-core:24132]:
> Even considering the current lack of a simple test case that
> demonstrates the segfault, does anyone have any speculation regarding
> what may be the underlying reason why DATA_PTR(obj) could sometimes be
> null before run_final gets called?

If DATA_PTR is 0, the object should not be deferred to release.
Can you see which class instance (or what dfree) causes the issue?