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 703960 - Interfaces are leaked when retrieving enums and flags
Interfaces are leaked when retrieving enums and flags
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: general
Git master
Other Linux
: Normal minor
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks: 693111
 
 
Reported: 2013-07-10 17:09 UTC by Mike Gorse
Modified: 2013-07-10 22:41 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch. (3.33 KB, patch)
2013-07-10 17:16 UTC, Mike Gorse 		needs-work Details | Review
Updated patch. (2.95 KB, patch)
2013-07-10 22:06 UTC, Mike Gorse 		committed Details | Review

Description Mike Gorse 2013-07-10 17:09:50 UTC 
g_type_info_get_interface is called in several places when calling functions that return flags or enums. The returned interface should be freed with g_base_info_unref.

The leaks can be seen when running make check.valgrind if G_DEBUG is set to always-malloc.
Comment 1 Mike Gorse 2013-07-10 17:16:18 UTC 
Created attachment 248853 [details] [review]
Patch.

Add calls to g_base_info_unref() in a bunch of places.
Comment 2 Simon Feltman 2013-07-10 18:01:15 UTC 
Review of attachment 248853 [details] [review]:

Thanks for this. One potential problem described below:

::: gi/pygi-marshal-from-py.c
@@ +1631,3 @@
     }
 
+    ret = TRUE;

Won't this always clobber the ret value with TRUE even after it is set in error case above? I'd be fine with either an explicit call to unref in the error case or moving "ret = TRUE" closer to where the variable is declared.
Comment 3 Simon Feltman 2013-07-10 18:01:16 UTC 
Review of attachment 248853 [details] [review]:

Thanks for this. One potential problem described below:

::: gi/pygi-marshal-from-py.c
@@ +1631,3 @@
     }
 
+    ret = TRUE;

Won't this always clobber the ret value with TRUE even after it is set in error case above? I'd be fine with either an explicit call to unref in the error case or moving "ret = TRUE" closer to where the variable is declared.
Comment 4 Mike Gorse 2013-07-10 22:06:23 UTC 
Created attachment 248883 [details] [review]
Updated patch.

Good catch. I've just added an unref in the error case and removed the variable.
Comment 5 Simon Feltman 2013-07-10 22:41:32 UTC 
Looks good now, thanks!