After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 619245 - GType used by hook_up_vfunc_impl is not the right one when __gtype_name__ is not set.
GType used by hook_up_vfunc_impl is not the right one when __gtype_name__ is ...
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2010-05-20 22:57 UTC by Steve Frécinaux
Modified: 2011-02-09 17:46 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Short test case. (244 bytes, text/x-python)
2010-05-20 22:57 UTC, Steve Frécinaux 		  Details
Fix crash in hook_up_vfunc_implementation when implementing GInterface (1.42 KB, patch)
2010-05-21 09:26 UTC, Steve Frécinaux 		rejected Details | Review

Description Steve Frécinaux 2010-05-20 22:57:50 UTC 
Created attachment 161597 [details]
Short test case.

When trying to implement a GInterface, there is a crash in pygi. Attached is a very simple test case.

Here is a bit of stacktrace:

Program received signal SIGSEGV, Segmentation fault.
0xb7aaee25 in _wrap_pyg_hook_up_vfunc_implementation (self=0x0, args=0x825c554) at gimodule.c:208
208	        *method_ptr = closure->closure;
(gdb) bt

+ Trace 222026

  • #0 _wrap_pyg_hook_up_vfunc_implementation
    at gimodule.c line 208
  • #1 call_function
    at ../Python/ceval.c line 3612
  • #2 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2304
  • #3 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2875
  • #4 fast_function
    at ../Python/ceval.c line 3708
  • #5 call_function
    at ../Python/ceval.c line 3633
  • #6 PyEval_EvalFrameEx
    at ../Python/ceval.c line 2304
  • #7 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2875
  • #8 function_call
    at ../Objects/funcobject.c line 517
  • #9 PyObject_Call
    at ../Objects/abstract.c line 1861
  • #10 instancemethod_call
    at ../Objects/classobject.c line 2519
  • #11 PyObject_Call
    at ../Objects/abstract.c line 1861
  • #12 slot_tp_init
    at ../Objects/typeobject.c line 4976
  • #13 type_call
    at ../Objects/typeobject.c line 438
  • #14 PyObject_Call
    at ../Objects/abstract.c line 1861
  • #15 PyObject_CallFunctionObjArgs
    at ../Objects/abstract.c line 2091
  • #16 build_class
    at ../Python/ceval.c line 4134
  • #17 PyEval_EvalFrameEx
    at ../Python/ceval.c line 1737
  • #18 PyEval_EvalCodeEx
    at ../Python/ceval.c line 2875
  • #19 PyEval_EvalCode
    at ../Python/ceval.c line 514
  • #20 run_mod
    at ../Python/pythonrun.c line 1273
  • #21 PyRun_FileExFlags 

Versions involved:
pygobject 2.21.1
pygi master (21/5/2010)
python 2.5.5
Comment 1 Steve Frécinaux 2010-05-21 08:53:04 UTC 
In gimodule.c, in _wrap_pyg_hook_up_vfunc_implementation:

The following lines are only triggered in the GInterface case:

implementor_iface_class = g_type_interface_peek(implementor_class,
                                                ancestor_g_type);
implementor_class = implementor_iface_class;

implementor_iface_class is null, hence
method_ptr = G_STRUCT_MEMBER_P(implementor_class, offset) is null too.


The values for the variables listed here are:
DEBUG: implementor_class = 0x9bc1ce0
DEBUG: implementor_iface_class = (nil)
DEBUG: ancestor_g_type = GtkEditable (163453552)

So basically it looks like implementor_gtype doesn't actually implement the GInterface...
Comment 2 Steve Frécinaux 2010-05-21 09:26:37 UTC 
Created attachment 161619 [details] [review]
Fix crash in hook_up_vfunc_implementation when implementing GInterface

If you don't set a __gtype_name__ attribute in your new GType when
implementing a GInterface, then for some reason g_type_interface_peek()
returns NULL and this causes hook_up_vfunc_implementation to crash.

This patch doesn't fix the g_type_interface_peek() issue, but it at
least avoids the crash by raising an exception instead.
Comment 3 Steve Frécinaux 2010-05-21 09:36:06 UTC 
Finally, it looks like the type passed to hook_up_vfunc_implementation is actually GtkWidget, not the type inheriting from both GtkWidget and GtkEditable.

Also, it works when setting __g_type_name__ in the new class, because it triggers the gtype registration.

As tomeu noticed, this means that the issue is actually triggered by the fact that the type hierarchies are not in sync between python and gtype: the type is already registered in python, but not yet in gtype, so we get the wrong class, and that class has no ginterface yet...
Comment 4 Steve Frécinaux 2010-05-21 13:11:11 UTC 
bug 616849 patch looks similar to the patch above, but it still wouldn't fix the fact that we can't implement a GInterface when we don't use __gtype_name__.
Comment 5 Steve Frécinaux 2010-05-21 13:40:33 UTC 
Review of attachment 161619 [details] [review]:

Using patch from bug 616849, the crash is totally fixed and warns about how one has forgotten to use __gtype_name__. I'm rejecting this patch and changing the subject of the bug.
Comment 6 Steve Frécinaux 2011-02-09 17:46:08 UTC 
This has been resolved by systematically registering a new gtype at the Prage Python Hackfest 2011.