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 756109 - Fix marshalling of user data arguments to callback
Fix marshalling of user data arguments to callback
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
: 756087 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-10-06 07:17 UTC by Giovanni Campagna
Modified: 2015-10-10 22:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix marshalling of user data arguments to callback (4.45 KB, patch)
2015-10-06 07:17 UTC, Giovanni Campagna
none Details | Review

Description Giovanni Campagna 2015-10-06 07:17:28 UTC
When the callback is marshalled, it will put something in the
arg cache. Make sure we recognize it before the closure detection
code overwrites it with the C gpointer closure arg.

Fixes GLib.idle_add(lambda x: False, None) in pygobject 3.18 and
master.
Comment 1 Giovanni Campagna 2015-10-06 07:17:34 UTC
Created attachment 312711 [details] [review]
Fix marshalling of user data arguments to callback
Comment 2 Christoph Reiter (lazka) 2015-10-06 08:41:53 UTC
*** Bug 756087 has been marked as a duplicate of this bug. ***
Comment 3 Christoph Reiter (lazka) 2015-10-06 09:06:24 UTC
Could you add some info on why this worked before and what broke/changed it?
Comment 4 Giovanni Campagna 2015-10-06 20:16:32 UTC
I have no idea to be honest :)

I only sporadically use pygobject apps. I was testing gnome-news yesterday and I found that it would fail to load, claiming that GLib.idle_add (aka g_idle_add_full) only takes 2 arguments, not 3.
Further gdb'ing revealed that the arg cache code fails to recognize the user_data varying argument (the index is -1 when the invoke code runs), and this patch is my guess for why that happens.

As for what changed in the particular case, someone added (closure) to the user_data argument in glib some time this cycle (or maybe after 3.18?), which means that get_closure() on that argument returns the argument number (as espected). Before it would return -1 (and it would return the closure number when called on the callback argument).
Comment 5 Christoph Reiter (lazka) 2015-10-10 16:54:56 UTC
(In reply to Giovanni Campagna from comment #4)
> As for what changed in the particular case, someone added (closure) to the
> user_data argument in glib some time this cycle (or maybe after 3.18?),
> which means that get_closure() on that argument returns the argument number
> (as espected). Before it would return -1 (and it would return the closure
> number when called on the callback argument).

Hm, why is that expected? get_closure is documented to return the user_data index for callbacks afaics, or am I missing something?

Filed bug 756352 in gi