GNOME Bugzilla – Bug 796013
Memory Leak When Deleting List of Objects
Last modified: 2018-05-22 16:02:43 UTC
Created attachment 371908 [details] [review] Adds function to check for object, and unrefs the data before calling delete_link(). The glib-2.0 Vapi bindings for g_list_delete_link do not take objects into account when freeing the list, despite using Generic type which can accept object types. Patch adds functionality to check for object and unrefs the data before calling delete_link().
*.delete_link() is not suppose to free the actual data. It only frees the list-structure of the given element. You always need to set the .data field to null despite its type.
Making the GLib collection types more Vala friendly seems like a good idea to me. Can you provide an example showing how the Vala code would look using your delete_obj_link() method. Can you also explain what [ReturnsModifiedPointer ()] does. ReturnsModifiedPointer is listed in vala/usedattr.vala and documented in the Legacy Bindings document, but I'm not sure the parentheses should be there. I recently updated the Collections section of https://wiki.gnome.org/Projects/Vala/LegacyBindings#Collections with more details of integrating a binding with foreach. It would be nice to have foreach work with GLib.List. Looking at it quickly I think a binding mapping g_list_nth_data () to get () in Vala and binding g_list_length () to a Vala size property should make GLib.List iterabale. What do people think?
Comment on attachment 371908 [details] [review] Adds function to check for object, and unrefs the data before calling delete_link(). Hmm, I'm thinking the CCode free_function should be changed to https://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html#g-list-free-full or a Vala wrapper around that.
> I recently updated the Collections section of > https://wiki.gnome.org/Projects/Vala/LegacyBindings#Collections with more > details of integrating a binding with foreach. It would be nice to have > foreach work with GLib.List. Looking at it quickly I think a binding mapping > g_list_nth_data () to get () in Vala and binding g_list_length () to a Vala > size property should make GLib.List iterabale. What do people think? foreach is properly working for GLib.List and GLib.SList https://git.gnome.org/browse/vala/tree/tests/methods/iterator.vala#n73
(In reply to Rico Tzschichholz from comment #4) > foreach is properly working for GLib.List and GLib.SList > https://git.gnome.org/browse/vala/tree/tests/methods/iterator.vala#n73 Thanks, I never knew there was a glist_type and gslist_type in the Vala compiler. Looks like the iterator code is fairly deeply embedded in the compiler: https://git.gnome.org/browse/vala/tree/codegen/valaccodecontrolflowmodule.vala#n287 with some checking of the profile in the Vala foreachstatement code node: https://git.gnome.org/browse/vala/tree/vala/valaforeachstatement.vala#n179 My gut feeling is that code should be refactored out some day so there is one less gobject profile dependency, but that's probably very low priority.
(In reply to Al Thomas from comment #3) > Hmm, I'm thinking the CCode free_function should be changed to > https://developer.gnome.org/glib/stable/glib-Doubly-Linked-Lists.html#g-list- > free-full or a Vala wrapper around that. This won't work like that and it is already done by vala itself while List/SList/Queue are special types handled in several places. These types are based on simple-generics and therefore type information are resolved on compile-time and not stored anywhere. This makes the usage of custom vala methods which rely on generic-type information impossible.
(In reply to Mike Koogle from comment #0) > Created attachment 371908 [details] [review] [review] > Adds function to check for object, and unrefs the data before calling > delete_link(). > > The glib-2.0 Vapi bindings for g_list_delete_link do not take objects into > account when freeing the list, despite using Generic type which can accept > object types. > > Patch adds functionality to check for object and unrefs the data before > calling delete_link(). It don't see how you were able to confirm that this works. You need to stay closer to C-API here and set *.data = null before calling delete_link() in the original scope. A custom vala method won't work here.
Hmm, wondering if this is a duplicate of Bug 646783 (https://bugzilla.gnome.org/show_bug.cgi?id=646783)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/627.