GNOME Bugzilla – Bug 574306
gperl_callback_invoke() reference leak
Last modified: 2009-06-06 17:44:23 UTC
With the current cvs and debian i386 perl 5.10.0, in the additions to GtkHBox.t below the last test case fails. The two new tests ask that a label widget is destroyed when weakened, after it's been added to and removed from the box. The first test succeeds, but the second test, where the label has also been subject to a $box->foreach, fails. Some digging suggests gperl_callback_invoke() is incrementing the C-side ref_count, ie. g_object_ref(), and never unreffing. I believe it may be due to not having g_value_unset(), per change below. I don't think anywhere in Glib-Perl itself puts objects through GPerlCallback, to exercise the problem, hence a test case only for gtk. I noticed it with GtkTreeModelFilter when calling out to a "modify" function, but gtk_container_foreach() is a much simpler failing example.
Created attachment 130154 [details] [review] failing .t case
Created attachment 130155 [details] [review] patch for gperl_callback_invoke()
Wow, that's a gigantic leak. Patch committed, thanks!
I had moved the GValue variable out of the loop since g_value_unset() clears it to zeros, no need for a fresh initializer to do that ... which may save 2 nanoseconds.
I didn't apply that part of the patch because it didn't seem related to the leak. Do you think it's worth applying the change now, given the decrease in readability it entails? (The variable is declared farther from where it's used, and it's not obvious that g_value_unset zero-fills the value, even though it's documented.)
So much of glib/gtk is poorly documented it makes you want to use the things that are documented! :-) I get the impression set/unset/set/unset is the intended pattern for a given GValue location.
OK, I just committed the optimization part of your original patch.