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 657442 - Possible leak in _pygi_argument_from_g_value()
Possible leak in _pygi_argument_from_g_value()
Status: RESOLVED FIXED
Product: pygobject
Classification: Bindings
Component: gobject
unspecified
Other Linux
: Normal minor
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on: 685275 726999
Blocks: 693111
 
 
Reported: 2011-08-26 13:48 UTC by Xavier Claessens
Modified: 2014-08-18 08:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Xavier Claessens 2011-08-26 13:48:23 UTC
It does g_value_dup_string() but all other types are not copied.
Comment 1 johnp 2011-08-26 17:00:43 UTC
No, string handling is quite different from other types which are ref counted.
Comment 2 Xavier Claessens 2011-08-26 18:00:10 UTC
Nothing free that string from pygi_signal_closure_marshal(), or am I overlooking something?
Comment 3 Xavier Claessens 2011-08-29 11:27:43 UTC
found 2 other issues in that function:
1) g_value_get_enum will assert if it holds G_TYPE_FLAGS
2) GParamSpec is considered anGI_INFO_TYPE_OBJECT, so it also have to be special-cased there to do g_value_get_param() instead of g_value_get_object() otherwise it will warning.
Comment 4 Martin Pitt 2012-04-23 17:50:18 UTC
(In reply to comment #2)
> Nothing free that string from pygi_signal_closure_marshal(), or am I
> overlooking something?

I think that's correct. Our current tests do not cover that code path, so we should add a test for this.

(In reply to comment #3)
> found 2 other issues in that function:
> 1) g_value_get_enum will assert if it holds G_TYPE_FLAGS

This should be fixed in the current code:

                case GI_INFO_TYPE_FLAGS:
                    arg.v_long = g_value_get_flags (value);
                    break;
                case GI_INFO_TYPE_ENUM:
                    arg.v_long = g_value_get_enum (value);
                    break;


> 2) GParamSpec is considered anGI_INFO_TYPE_OBJECT, so it also have to be
> special-cased there to do g_value_get_param() instead of g_value_get_object()
> otherwise it will warning.

I cannot currently confirm this, as currently it is impossible (or very hard) to instantiate a ParamSpec with PyGI. Once that is fixed, this should also get a test case.
Comment 5 Simon Feltman 2014-07-30 05:58:10 UTC
Memory leaks mentioned will be fixed in work done with bug 726999.
Comment 6 Simon Feltman 2014-08-18 08:35:54 UTC
Fixed with bug 726999