For more info see https://bugs.gentoo.org/show_bug.cgi?id=466794

Martin, this is very vague.

This is certainly not a regression in GTK+, the line which your stack
trace refers to has been the same forever.

It looks to me there are 2 possible scenarios:

   a.) You've given gtk_builder_connect_signals_full() a pointer
       to something that is not a native C GtkBuilderConnectFunc pointer

   b.) The native C GtkBuilderConnectFunc that you've given to
       gtk_builder_connect_signals_full is crashing somewhere (but as
       it's a static function somewhere, we don't see exactly how
       it's crashing).

It's unlikely but possible that we're experiencing 'a', but that would
indicate that python bindings made a sort of naive assumption that you
could just use GObject Introspection carelessly (and I doubt that, afaik
python bindings usually work ;-))

To clarify, gtk_builder_connect_signals_full() is specifically made for
the sake of bindings, so that bindings can offer a custom API to connect
callbacks in the given language by providing a native C implementation.

The idea that gtk_builder_connect_signals_full() is being invoked by ffi
here looks rather inappropriate.

I'm sorry that I didn't provide more information, but I can post coredumps here as well as basically anything you'll ask for,  I just didn't know which pieces of information are relevant.

I'm not very skilled with gtk/gobject/glib, but since this occurs in more programs, I assume it might be a problem in underlying libraries, the code which ought to be called should be OK, but that's neither part of d-feet nor virt-manager AFAIK.

From what I was looking at, the 'func' cannot be called, because it is always some invalid pointer and that's where the segfault is caused.  Same code works OK on different system (distro, package versions etc.), but TBH, I'm not sure what packages I should be checking for version differences.

Let me know how I can help with haunting this problem down, I'm willing to get you all the info you need.  This also might not be the right component, but as I mentioned earlier, not being expert on this means I just checked out the package that provided the code the programs are crashing in.

Martin, my suspicion is that this is a problem in a given version
of the pygobject bindings.

A good start would be to first find a version of pygobject & d-feet where
the crash is absolutely reproducible, as you mentioned you've tried various
versions of GTK+ and this doesnt seem to change anything.

An obvious next step would be to verify that the crash still happens
when using pygobject master (or most recent version possible), if it's been
fixed then perhaps backporting the fix is possible.

The reason I'm pointing the finger at pygobject here, is because I presume
that somewhere d-feet is calling GtkBuilder.connect_signals() and pygobject
is not providing a custom native C GtkBuilderConnectFunc to
gtk_builder_connect_signals_full(), but instead passing some python object
down to the C interface. My suspicion is that pygobject is just relying
on GObject Introspection to do all the dirty work for free.

Another possibility is that d-feet is calling GtkBuilder.connect_signals_full()
(which might somehow be available in python, when it shouldn't)... when
d-feet should just be calling GtkBuilder.connect_signals() and letting the
pygobject bindings do the custom magick of connecting a python callback with
native C code.

This happens around #8 or #9 of your attached stack trace, where it's difficult
to see why but, somehow gtk_builder_connect_signals_full() is being called
directly with libffi... what *should* be happening instead, is that d-feet
calls GtkBuilder.connect_signals(), and the custom code in pygobject calls
gtk_builder_connect_signals_full() and provides a GtkBuilderConnectFunc in C which knows how to connect a python callback to a GSignal (probably by using
a custom GClosure)

The following is still unclear to me:
  o Is PyGObject missing the custom code to implement GtkBuilderConnectFunc ?
  o Is D-Feet calling GtkBuilder.connect_signals_full() when it should be
    calling GtkBuilder.connect_signals() ? ...
  o Is GtkBuilder.connect_signals_full() somehow visible from python, when
    it actually should not be ?

The crash is easily reproducible with both d-feet and virt-manager, I just forgot to have a look at most recent version available of pygobject, I simple took the latest in my distro (3.8.1).  Now I tried to reproduce this issue with pygobject from git and d-feet from git, it's still 100% reproducible :(

Versions:
d-feet from git: 0.3.1-10-gd48687d
pygobject from git: 3.8.1-3-g2a1c09f
gobject-introspection-common-1.36.0
gobject-introspection-1.36.0
glib-2.36.0
gdbus-codegen-2.36.0

Neither virt-manager nor d-feet are running connect_signals_full(), both of them use connect_signals() only.

Don't hesitate to change the Product/Component to anything else that might be more related.


BTW: Even though it is not used anywhere, connect_signals_full is available from python (but might be wrapped with another python code):

 $ python -c 'from gi.repository import Gtk; print "connect_signals_full" in dir(Gtk.Builder())'
 True

I managed to fix this issue with 'emerge -e world'.

Feel free to resolve it as anything appropriate, sorry for wasting your time and thanks for all the responses.

Resolving as OBSOLETE... for lack of a resolution named INCIDENT.

Thanks for following up.