GNOME Bugzilla – Bug 633927
Crash when calling signal matching functions
Last modified: 2013-05-02 02:11:24 UTC
The following minimal program causes crashes on each of the print lines: from gi.repository import GObject obj = GObject.GObject() def dummy(*args, **kwargs): pass print GObject.signal_handlers_block_matched(obj, 0, 0, 0, dummy, 0, 0) print GObject.signal_handlers_unblock_matched(obj, 0, 0, 0, dummy, 0, 0) print GObject.signal_handlers_disconnect_matched(obj, 0, 0, 0, dummy, 0, 0) The dummy function is because the bindings require that argument to be a 'callable', so you can't pass 0 or None for it.
+ Trace 224472
if you look at the backtrace you will notice that we end up calling the function like this: g_signal_handlers_block_matched (instance=0x7fba50, mask=0, signal_id=0, detail=0, closure=0xb71ec0, func=0x7ffff7dc0400, data=0x7ffff7dc0400) func and data were set to 0 so this looks completely wrong. We are trashing the stack somewhere. Most likely when looking up the closure info. BTW, these methods aren't in the static bindings are they? If they are not I would rather think of these methods as nonwrappable and if you need the functionality, have them make a wrappable function in Gtk3.
These methods are not in the static bindings (as neither are other signal handler functions like signal_find_handler). But I see that as a bug in the static bindings, as these are useful functions. What do you mean about Gtk3? Do you mean I should propose a wrappable function for GLib 2.28? I don't know enough about Python/C integration to know what makes the existing function unwrappable.
Sorry, yes. I meant propose a patch to GLib. The issue is we only support a small subset of what can be described in C. A lot of things like va_lists are completely unsupported since they are compile time constructs. In the case of the methods you are trying to use, they contain a lot of generic gpointers, a GQuark and a closure. guint g_signal_handlers_block_matched (gpointer instance, GSignalMatchType mask, guint signal_id, GQuark detail, GClosure *closure, gpointer func, gpointer data); It might be that I just need to annotate the gpointer data as user data for the closure. However the gpointer func throws up a red flag. Even the docs say this is useless for non C callbacks. In any case I'll try some stuff and ask around but I'm hesitant to spend too much time on this since it isn't supported in older versions and may very well be involved to support. I'm not even sure if we support GQuarks.
OK, I filed bug 633999 asking for a more bindable API.
Still an issue with 3.2. This sounds by and large "wontfix", it'd probably be better to (skip) this API in glib.
I am also observing these crashes with the following GObject namespace functions: signal_handler_block signal_handler_unblock signal_handler_disconnect signal_handler_is_connected signal_stop_emission signal_stop_emission_by_name These are some of the simpler functions exposed with the same problem. Essentially they all take "gpointer instance" as the first argument. I've logged bug 688081 which is the root cause of the crash. A large amount of these functions could actually work if bug 688081 is fixed in combination with exposing the pointer of a GObject as an integer value (something like Object.__gpointer__). So a working override for one of the above functions would then look like this: @override def signal_handler_block(obj, handler_id): return GObjectModule.signal_handler_block(obj.__gpointer__, handler_id) If this is not desired we should definitely either use (skip) or override the functions to raise an exception stating they are unsupported in python.
Created attachment 236883 [details] [review] Fix crashes in various GObject signal handler functions Fix crashes in a large amount of signal handler functions exposed on the GObject module. This is possible now that the underlying GObject pointer is exposed to Python as a PyCapsule which marshaling can handle. The following functions in the GObject module have been verified: signal_handler_unblock signal_handler_disconnect signal_handler_is_connected signal_stop_emission signal_stop_emission_by_name signal_has_handler_pending signal_connect_closure signal_connect_closure_by_id signal_handler_find signal_handlers_destroy The following function don't crash, but also don't work right do to there being no mapping from a Python callback to a GClosure for the matching: signal_handlers_block_matched signal_handlers_unblock_matched signal_handlers_disconnect_matched I think these will be fixed in: https://bugzilla.gnome.org/show_bug.cgi?id=692918 as it also needs to deal with handler_block_by_func and handler_unblock_by_func.
Comment on attachment 236883 [details] [review] Fix crashes in various GObject signal handler functions Great work Simon, thanks!
Attachment 236883 [details] pushed as 80ed803 - Fix crashes in various GObject signal handler functions