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 616236 - Fix GAsyncReadyCallback
Fix GAsyncReadyCallback
Status: RESOLVED FIXED
Product: pygi
Classification: Deprecated
Component: general
unspecified
Other All
: Normal normal
: 0.6
Assigned To: pygi-maint
pygi-maint
Depends on:
Blocks:
 
 
Reported: 2010-04-19 23:24 UTC by Tomeu Vizoso
Modified: 2010-04-30 16:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix GAsyncReadyCallback (2.29 KB, patch)
2010-04-19 23:24 UTC, Tomeu Vizoso
none Details | Review
Fix GAsyncReadyCallback (2.26 KB, patch)
2010-04-30 13:02 UTC, Tomeu Vizoso
committed Details | Review

Description Tomeu Vizoso 2010-04-19 23:24:39 UTC
It's broken because of some magic going on with closure->user_data
Comment 1 Tomeu Vizoso 2010-04-19 23:24:41 UTC
Created attachment 159124 [details] [review]
Fix GAsyncReadyCallback
Comment 2 Zach Goldberg 2010-04-21 03:13:36 UTC
Review of attachment 159124 [details] [review]:

Yeah, I figured this would bite is eventually.  There is no perfect way to check that this argument is the callback and is what we're looking for (at least not that Colin and I could come up with @ the hackfest)

I don't entirely understand how your patch tries to fix that though.  You're checking if a null pointer is passed in and in that case using Py_None.  I guess your assumption is that valid pointers will be NULL whereas the callback will be a junk pointer?
Comment 3 Tomeu Vizoso 2010-04-23 12:17:34 UTC
(In reply to comment #2)
> Review of attachment 159124 [details] [review]:
> 
> Yeah, I figured this would bite is eventually.  There is no perfect way to
> check that this argument is the callback and is what we're looking for (at
> least not that Colin and I could come up with @ the hackfest)
> 
> I don't entirely understand how your patch tries to fix that though.  You're
> checking if a null pointer is passed in and in that case using Py_None.  I
> guess your assumption is that valid pointers will be NULL whereas the callback
> will be a junk pointer?

Well, this patch just makes sure that if we are passed NULL, we don't try to interpret it as a PyObject* (and crash) and instead pass None.

About the root issue you mention, I cannot say I understand it fully, can you extend on it?
Comment 4 Zach Goldberg 2010-04-25 05:17:30 UTC
The issue is that we do not know which argument the callback is.  We can't surround the insertion of the callback with a check that the argument is NULL because that could be valid and it may be a case where we need the callback.
Comment 5 Tomeu Vizoso 2010-04-26 14:08:18 UTC
(In reply to comment #4)
> The issue is that we do not know which argument the callback is.  We can't
> surround the insertion of the callback with a check that the argument is NULL
> because that could be valid and it may be a case where we need the callback.

I see the difficulties with that, but this patch just makes sure we don't pass NULL as a Python object.

Properly identifying the user_data args should be a separate bug.
Comment 6 Zach Goldberg 2010-04-26 16:22:35 UTC
The issue is that you're checking if:

if (*((gpointer*)args[i]) == NULL) {


However, inside this case statement the only thing we could be passing to python is

closure->user_data

so I am confused how the check helps at all?
Comment 7 Tomeu Vizoso 2010-04-30 13:02:03 UTC
Created attachment 159977 [details] [review]
Fix GAsyncReadyCallback

You are right, sorry for not understanding before. This patch addresses
it and is rebased against HEAD.
Comment 8 Zach Goldberg 2010-04-30 14:34:43 UTC
Review of attachment 159977 [details] [review]:

Looks good to me!  Thanks for bearing with me with my poor explanations :)
Comment 9 Tomeu Vizoso 2010-04-30 16:21:12 UTC
Attachment 159977 [details] pushed as 9fc6783 - Fix GAsyncReadyCallback