This bug may be the result of Vala or the GObject/GType runtime system. The
crux of the problem is basically this:

(i) Define an interface:

public interface Doable : Object {
   public abstract int some_method(int input);
}

(ii) Define an abstract class that implements the interface, including
a concrete implementation of some_method( ):

public abstract class Gizmo : Object, Doable {
   public int some_method(int input) {
       return input + 1;
   }
}

(iii) Define a concrete class that extends Gizmo, but make it
redundantly require the Doable interface (this is redundant because
all Gizmos already are Doable)

public class Thingamajig : Gizmo, Doable {
   public char some_other_method() {
       return 'j';
   }
}

(iv) Now, attempt to call some_method() on a Thingamajig:

Thingamajig t = new Thingamajig();
int i = t.some_method(42);

This will cause a segfault. Moreover, if you look at the stack trace,
before the segfault you'll see a pattern of thousands of recursive
calls as the GObject runtime system attempts to resolve some_method( )
to an actual function pointer so that it can invoke it.

If you want to eliminate the segfault, you need only change the
definition of class Thingamajig to this:

public class Thingamajig : Gizmo {
   public char some_other_method() {
       return 'j';
   }
}

Note that the semantics of Thingamajig's definition are exactly what
they were before -- a Thingamajig is still Doable because its
superclass Gizmo is Doable. But we've removed the redundant reference
to Doable in the definition of Thingamajig. In this latter case, the
GObject runtime system has no problem resolving some_method( ), so we
get no segfault.