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 633927 - Crash when calling signal matching functions
Crash when calling signal matching functions
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: introspection
2.21.x
Other Linux
: Low minor
: GNOME 3.8
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on: 633999
Blocks: 699435
 
 
Reported: 2010-11-03 17:35 UTC by Michael Terry
Modified: 2013-05-02 02:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix crashes in various GObject signal handler functions (19.41 KB, patch)
2013-02-20 03:17 UTC, Simon Feltman
committed Details | Review

Description Michael Terry 2010-11-03 17:35:56 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.
Comment 1 johnp 2010-11-03 19:09:15 UTC


  • #0 g_type_check_instance
    at gtype.c line 4048
  • #1 g_signal_handlers_block_matched
    at gsignal.c line 2576
  • #2 ffi_call_unix64
    at src/x86/unix64.S line 75
  • #3 ffi_call
    at src/x86/ffi64.c line 484
  • #4 g_function_info_invoke
    at gifunctioninfo.c line 417
  • #5 _invoke_function
  • #6 _wrap_g_function_info_invoke

Comment 2 johnp 2010-11-03 19:13:31 UTC
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.
Comment 3 Michael Terry 2010-11-03 19:37:52 UTC
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.
Comment 4 johnp 2010-11-03 19:56:47 UTC
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.
Comment 5 Michael Terry 2010-11-04 15:19:38 UTC
OK, I filed bug 633999 asking for a more bindable API.
Comment 6 Martin Pitt 2012-04-24 14:12:39 UTC
Still an issue with 3.2. This sounds by and large "wontfix", it'd probably be better to (skip) this API in glib.
Comment 7 Simon Feltman 2012-11-11 08:56:25 UTC
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.
Comment 8 Simon Feltman 2013-02-20 03:17:22 UTC
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 9 Martin Pitt 2013-02-22 06:49:58 UTC
Comment on attachment 236883 [details] [review]
Fix crashes in various GObject signal handler functions

Great work Simon, thanks!
Comment 10 Simon Feltman 2013-02-22 08:02:30 UTC
Attachment 236883 [details] pushed as 80ed803 - Fix crashes in various GObject signal handler functions