I could not produce this error with folks_0_7_3. Its new with folks 0.9.1.1.20130520

Simon, this is SmallSet stuff. Any ideas?

> ** (gnome-chess:22278): CRITICAL **: Type `FolksSmallSet' does
> not implement abstract method `gee_abstract_collection_iterator'

Er, it looks to me as though it does?

  static void
  folks_small_set_class_init (FolksSmallSetClass *cls)
  {
  ...
    GeeAbstractCollectionClass *ac_class = GEE_ABSTRACT_COLLECTION_CLASS (cls);
  ...
    ac_class->iterator = folks_small_set_iterator;

Chandni, what versions of Gee and Vala are you using? If you compiled Gee yourself, which version of Vala did you use for that? If you got it from a distribution, which one?

It's possible that folks-generics.vapi ought to say which methods it overrides, but I would have thought that would result in failure at compile-time rather than runtime...

Created attachment 246983 [details] [review]
folks-generics.vapi: say what we override in the C code

---

Does this help?

(In reply to comment #3)
> Chandni, what versions of Gee and Vala are you using? If you compiled Gee
> yourself, which version of Vala did you use for that? If you got it from a
> distribution, which one?

I have gee-0.8 version 0.10.0 built using Vala 0.20.1.14-b942

(In reply to comment #5)
> folks-generics.vapi: say what we override in the C code

Please try applying that to Folks. If that doesn't work, also try recompiling your application against the patched Folks.

I tried but I still get the same error and backtrace. Just a query, libfolks-internal.la is a noinst_LTLIBRARIES so it won't be installed. Are you sure it should remain such?

(In reply to comment #8)
> Just a query,
> libfolks-internal.la is a noinst_LTLIBRARIES so it won't be installed. Are you
> sure it should remain such?

Yes. It's an uninstalled static library (a libtool "convenience library") which gets copied into the main library (libfolks.la).

Please get a backtrace with G_DEBUG=fatal-criticals so we can see where the critical warning comes from?

It looks likely to be this (in the generated C code):

static GeeIterator* gee_abstract_collection_real_iterator (GeeAbstractCollection* self) {
        g_critical ("Type `%s' does not implement abstract method `gee_abstract_collection_iterator'", g_type_name (G_TYPE_FROM_INSTANCE (self)));
        return NULL;
}

GeeIterator* gee_abstract_collection_iterator (GeeAbstractCollection* self) {
        g_return_val_if_fail (self != NULL, NULL);
        return GEE_ABSTRACT_COLLECTION_GET_CLASS (self)->iterator (self);
}

... but we definitely do set GeeAbstractCollectionClass.iterator, as quoted above? So I don't know why gee_abstract_collection_real_iterator() would ever be called...

backtrace with G_DEBUG=fatal-criticals :

(gnome-chess:2690): folks-WARNING **: backend-store.vala:409: Error preparing Backend 'ofono': GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files

** (gnome-chess:2690): CRITICAL **: Type `FolksSmallSet' does not implement abstract method `gee_abstract_collection_iterator'

Program received signal SIGTRAP, Trace/breakpoint trap.
0xb6d2f5eb in g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, 
    format=0xb7322820 "Type `%s' does not implement abstract method `gee_abstract_collection_iterator'", args=0xbfffdafc "\200\005\024\267")
    at gmessages.c:974
974			G_BREAKPOINT ();
(gdb) bt full

+ Trace 232079

(In reply to comment #6)
> (In reply to comment #3)
> > Chandni, what versions of Gee and Vala are you using? If you compiled Gee
> > yourself, which version of Vala did you use for that? If you got it from a
> > distribution, which one?
> 
> I have gee-0.8 version 0.10.0 built using Vala 0.20.1.14-b942

Are you sure you're using your self-built libgee? The backtrace says

> #3  0xb72eacdf in gee_abstract_collection_iterator () from
> /usr/lib/i386-linux-gnu/libgee.so.2

which looks a lot like Debian or Ubuntu libgee 0.6.x to me...

Ah, in fact, I think I might see the problem. I think your process has ended up with both libgee 0.6.x and 0.8+ in its process space, because one of your dependencies is linked against one and another is linked against the other. You can verify this with "libtool --mode=execute ldd gnome-chess" (or whatever your executable is called). If I'm right, you'll see both libgee.so.2 and libgee-0.8.so.2 in the ldd output.

If that's the case, then this is NOTOURBUG, and you will need to recompile any of your application's dependencies that currently use libgee.so.2 (libgee 0.6) against "libgee-0.8" (Gee 0.8+); this might require source changes to those dependencies, because Gee broke ABI and API between 0.6 and 0.8.

(Confusingly, the pkg-config name for libgee 0.6.x is "gee-1.0". Don't be fooled: that's actually older than libgee 0.8 and 0.10, whose pkg-config name is "gee-0.8".)

yes, I have both libgee.so.2 and libgee-0.8.so.2 in the ldd output. This is confusing.

Gee has made an ABI transition and your development environment is apparently halfway through it. You'll need to find any libraries used by your application that are linked to libgee.so.2, and compile a version of those libraries that uses libgee-0.8 instead (this might mean jhbuild'ing more things, for instance).

Strictly speaking, I think this might mean Folks should have bumped its SONAME when it moved from Gee 0.6 to 0.8. (It returns objects that used to conform to the Gee 0.6 ABI, but now conform to the Gee 0.8 ABI.)

Here's your bug, I think:

>    PKG_CHECK_MODULES([GEE], [gee-1.0])

You need to use the same ABI of Gee that Folks is using: Folks < 0.9.0 used gee-1.0, Folks >= 0.9.0 use gee-0.8.

That solves it. Thanks a lot!