I've written code that will pass all tests, but during benchmarking it will intermittently segfault. The code that rarely will segfault has this logic. It's Rust code called from Ruby

• 1) get the directory contents
• 2) convert strings to Value object
• 3) create AnyObject from Value
• 4) instantiate an instance of Pathname class with the Vec<AnyObject> single parameter from above
• 5) append each of those to Array and return it to Ruby

It's important to note that there are no problems with the kinds of characters retrieved from the directory (even though characters such as a null byte is valid text for a file name). The segfault typically shows up in the 8000+ iterations benchmark.

I don't read segfaults well but I understand the concept of narrowing down potential problem areas by benchmarking the heck out of specific sections of ruru.

Working Code

An important detail to add is I have a similar implementation which does the following:

• 1) get the directory contents
• 2) convert strings to a RString object
• 3) append each of those to an Array and return it to Ruby

And this never segfaults for me. This helps narrow down the problem area.

I was able to get Ubuntu to open a crash report. This looks like it has much more useful info.

The method referred to is here in the Ruby source code: vm_method.c#L721

Because of the localized area in which this happened I'm inclined to think this may be an issue something like https://github.com/tildeio/helix/issues/50

If we:

1) heap allocate a struct-based helix object (e.g. Duration::new) 2) GC runs

It will GC the Ruby object associated with the helix object, because the GC couldn't see the VALUE pointer on the stack

See sparklemotion/nokogiri@0a1556a and http://blog.reverberate.org/2016/06/12/native-extensions-memory-management-part1-ruby-mri.html

So I was able to get my code working but I had to not use new_instance on the Pathname class.

Here's the commit with what I changed https://github.com/danielpclark/faster_path/commit/e7b94c7a1fea5fb64afcc355565b39bd47718c2a

Instead of doing

Class::from_existing("Pathname").new_instance(
    Some(&vec![RString::new(path).to_any_object()])
)

I had to do

let mut path_instance = Class::from(
    Class::from_existing("Pathname").send("allocate", None).value()
);

path_instance.instance_variable_set(
    "@path",
    RString::new(path).to_any_object()
);

In my earlier use case of creating a new instance of Pathname it's running Ruby's C code to initialize it.

static VALUE
path_initialize(VALUE self, VALUE arg)
{
    VALUE str;
    if (RB_TYPE_P(arg, T_STRING)) {
        str = arg;
    }
    else {
        str = rb_check_funcall(arg, id_to_path, 0, NULL);
        if (str == Qundef)
            str = arg;
        StringValue(str);
    }
    if (memchr(RSTRING_PTR(str), '\0', RSTRING_LEN(str)))
        rb_raise(rb_eArgError, "pathname contains null byte");
    str = rb_obj_dup(str);

    set_strpath(self, str);
    OBJ_INFECT(self, str);
    return self;
}

The point of this error has been discovered and it was because Heap memory is used with Vec but Ruby's GC traces things down via the Stack.

Here's the relevant answer: https://github.com/danielpclark/rutie/issues/3#issuecomment-401515443

So this issue is more of a user error than a Ruru one.