GNOME Bugzilla – Bug 681565
Problem with GParamSpec return values: g_object_get_qdata() called on param spec
Last modified: 2012-08-20 20:56:54 UTC
Hi ! We have this function : http://fpaste.org/CPaG/ which gives an incorrect pointer for the GParamSpec. I couldn't find working examples for how to return such types, and I think the annotations are correct. I tried to set the transfer type to floating but no luck either. example output : Correct values : ges ges-track-object.c:1176:ges_track_object_lookup_child: pspec : 0x2c66800 elem : 0x11d5400 returned tuple in python: (True, <__main__.GstAgingTV object at 0x18dcf00 (GstAgingTV at 0x11d5400)>, <gi.repository.GObject.ParamSpecUInt object at 0x2279810>)
I made a little test program that calls gst_child_proxy_lookup(), which has a GParamSpec as one of the out arguments: It fails with: /usr/lib/python2.7/dist-packages/gi/types.py:43: Warning: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed return info.invoke(*args, **kwargs) /usr/lib/python2.7/dist-packages/gi/types.py:43: Warning: g_object_ref_sink: assertion `G_IS_OBJECT (object)' failed return info.invoke(*args, **kwargs) ** (python:27838): CRITICAL **: pygobject_register_wrapper: assertion `PyObject_TypeCheck(self, &PyGObject_Type)' failed (True, <__main__.GstPlayBin object at 0x7fccaa45b460 (GstPlayBin at 0x1bbe680)>, <gi.repository.GObject.ParamSpecObject object at 0x7fcca9ffdfd0>) Stack trace: tpm@zingle:~/gst/0.11/gstreamer$ G_DEBUG=fatal_warnings gdb --args python ../lookup-pspec.py (gdb) run Starting program: /usr/bin/python ../lookup-pspec.py (python:27852): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion `G_IS_OBJECT (object)' failed Program received signal SIGTRAP, Trace/breakpoint trap. g_logv (log_domain=0x7ffff6323f6c "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff586a6e2 "%s: assertion `%s' failed", args1=args1@entry=0x7fffffffbc78) at /tmp/buildd/glib2.0-2.32.3/./glib/gmessages.h:101 101 /tmp/buildd/glib2.0-2.32.3/./glib/gmessages.h: No such file or directory. (gdb) bt
+ Trace 230660
It looks like it tries to call g_object_get_qdata() on a GParamSpec, which is not a GObject: (gdb) print *object $1 = {g_type_instance = {g_class = 0x9a7b50}, ref_count = 4092817894, qdata = 0xe1} (gdb) print *((GParamSpec*)object) $2 = {g_type_instance = {g_class = 0x9a7b50}, name = 0x7ffff3f371e6 "source", flags = 225, value_type = 10409216, owner_type = 12622624, _nick = 0x7ffff3f36c6e "Source", _blurb = 0x7ffff3f380c6 "Source element", qdata = 0x0, ref_count = 2, param_id = 5}
Apologies, that trace was missing the most interesting bits since I didn't have debug symbols for pygobject/pygi installed. Here are the interesting bits then:
+ Trace 230661
Looking at the code in git master, this issue most likely still exists. _pygi_marshal_to_py_interface_object() calls pygobject_new() for the GParamSpec, and pygobject_new() assumes the passed pointer is a GObject. Not sure what the correct fix is - checking with G_IS_PARAM_SPEC and using pyg_param_spec_new() instead ? Would changes in other places be required too?
Thanks a lot for taking a look, that problem really is a blocker for us. I hope we can find a solution this week !
Created attachment 221319 [details] [review] This patch allows a discrimination between GObject and GParamSpecs I don't know if other types would need to be recognized as well ?
Comment on attachment 221319 [details] [review] This patch allows a discrimination between GObject and GParamSpecs Thanks for this! Patch looks fine, but I'd feel better with adding an API to GIMarshallingTests and adding a test case for this.
Created attachment 221893 [details] [review] Updates test_gi.py
Created attachment 221894 [details] [review] Updates gimarshallingtests
g-i test case cleaned up, and added an (out) variant as well: http://git.gnome.org/browse/gobject-introspection/commit/?id=4aed22c74b1 Finished pygobject test cases, and committed together with the patch: http://git.gnome.org/browse/pygobject/commit/?id=5cd18c9bd59 Thanks!