GNOME Bugzilla – Bug 707170
3.9.x regression: user defined signals: "TypeError: can't convert return value to desired type"
Last modified: 2013-09-02 03:20:49 UTC
The following raises an exception in 3.9.x but didn't before. ######################################## from gi.repository import GObject class Foo(GObject.Object): __gsignals__ = { 'test': (GObject.SignalFlags.RUN_LAST, None, (object,)), } def x(*args): print args foo = Foo() foo.connect("test", x) foo.emit("test", object())
I cannot reproduce this with either with Python 2.7 or Python 3.3. What architecture is this happening on?
py2.7, amd64, glib 2.36.4
Maybe it's because I'm using it uninstalled? I'm using "PYTHONPATH=<pygi-git> python foo.py"
(In reply to comment #3) > Maybe it's because I'm using it uninstalled? I'm using "PYTHONPATH=<pygi-git> > python foo.py" That could very well be the problem. Please verify the SOs are loaded from the correct locations (these are shown as relative from my pygi-git dir): import gi._gi gi._gi <module 'gi._gi' from './gi/_gi.cpython-33m.so'> import gi._glib._glib gi._glib._glib <module 'gi._glib._glib' from './gi/_glib/_glib.cpython-33m.so'> import gi._gobject._gobject gi._gobject._gobject <module 'gi._gobject._gobject' from './gi/_gobject/_gobject.cpython-33m.so'> More importantly and probably the problem, libpyglib-gi-2.0-python<ver>.so could be loaded from the system installed version. It looks like it is built into: ./gi/_glib/.libs/ So you might try pre-pending that to your LD_LIBRARY_PATH. You can verify the location with something like: os.system('lsof -p %s | grep pyglib' % os.getpid()) ipython3 27035 simon mem REG 8,1 32618 25696111 <...>libpyglib-gi-2.0-python3.3.so.0.0.0
Thanks for the instructions. It seems to load all libs locally. The problem seems to be that pyg_closure_marshal gets a GValue *return_value with G_VALUE_TYPE(return_value) == NULL. And pyg_value_from_pyobject_with_error raises TypeError("Unknown value type") for this. If that doesn't make any sense, it's probably my setup then. 2cff4827e6d15bcad630316a8a4e67968a70bbbf is the first bad commit commit 2cff4827e6d15bcad630316a8a4e67968a70bbbf Author: Simon Feltman <sfeltman@src.gnome.org> Date: Sat Jul 6 14:10:20 2013 -0700 Refactor pyg_value_from_pyobject into two functions Break pyg_value_from_pyobject into two functions. One which keeps Python exceptions queued (pyg_value_from_pyobject_with_error) and one which clears them (pyg_value_from_pyobject). This allows for re-use for code which want to keep the errors around https://bugzilla.gnome.org/show_bug.cgi?id=688081
I just upgraded to glib 2.37.6 and the error is gone.
Thanks for digging a bit deeper. I think this is a problem with release glib builds (not version related). If you look at how GClosureMarshals are called from signal emission, it shows only debug builds are setting the return value to NULL when the closure specifies it has no return: https://git.gnome.org/browse/glib/tree/gobject/gsignal.c?id=2.37.6#n3031 I consider this a bug in glib and logged it as bug #707249, but we can definitely react to it (again) in PyGObject so we don't regress.
Notes: I was able to verify this bug (and fix) by configuring glib with "--enable-debug=minimum". With this, the error shows up numerous times in our test suite but does not cause it to fail due to the error occurring within closures. This fix cleared all of these out with one exception which is an intended failure check: https://git.gnome.org/browse/pygobject/tree/tests/test_everything.py?id=3.9.90#n923
Committed as: https://git.gnome.org/browse/pygobject/commit/?id=dab0c09