Re: Would this leak be inside gtk?
I conclude this is a gtk memory leak. It occurs when calling gtk_combo_box_new_with_entry(), Apparently, when the dialog that contains the combo box is destroyed, the GList "visible_children" in file gtkcombobox.c is not being cleansed of the pointer to the child widget, entry. The leak does not occur if plain gtk_combo_box_new() is used instead. Correct me if I'm wrong. Here's a valgrind suppression entry: { libgtk:comboboxwithentry Memcheck:Leak fun:malloc fun:g_malloc fun:g_slice_alloc fun:g_list_prepend fun:gtk_combo_box_get_path_for_child fun:gtk_widget_get_path fun:reset_style_recurse fun:gtk_widget_set_parent fun:gtk_combo_box_add fun:g_closure_invoke } 2013/1/22 Edscott Wilson > > Would the following be a leak in the gtk library (which I should not worry > about), or a leak in my program ( http://xffm.org )? > > > ==19528== > ==19528== 24 bytes in 1 blocks are definitely lost in loss record 2,773 of > 9,919 > ==19528==at 0x4C2AABB: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==19528==by 0x8993114: g_malloc (in /usr/lib64/libglib-2.0.so.0.3000.2) > ==19528==by 0x89A8069: g_slice_alloc (in > /usr/lib64/libglib-2.0.so.0.3000.2) > ==19528==by 0x8986F8D: g_list_prepend (in > /usr/lib64/libglib-2.0.so.0.3000.2) > ==19528==by 0x5EF1E9A: gtk_combo_box_get_path_for_child (in > /usr/lib64/libgtk-3.so.0.200.4) > ==19528==by 0x60AC65B: gtk_widget_get_path (in > /usr/lib64/libgtk-3.so.0.200.4) > ==19528==by 0x60AC6F9: reset_style_recurse (in > /usr/lib64/libgtk-3.so.0.200.4) > ==19528==by 0x60B8276: gtk_widget_set_parent (in > /usr/lib64/libgtk-3.so.0.200.4) > ==19528==by 0x5EF1F83: gtk_combo_box_add (in > /usr/lib64/libgtk-3.so.0.200.4) > ==19528==by 0x8300C63: g_closure_invoke (in > /usr/lib64/libgobject-2.0.so.0.3000.2) > ==19528==by 0x83173A6: ??? (in /usr/lib64/libgobject-2.0.so.0.3000.2) > ==19528==by 0x8318DE8: g_signal_emit_valist (in > /usr/lib64/libgobject-2.0.so.0.3000.2) > > Gtk version: GTK+-3.2.4 > > Linux tauro 3.2.1-gentoo-r2 #3 SMP Tue Oct 16 09:47:16 CDT 2012 x86_64 > Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux > > Any clues will be kindly appreciated. > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
On Wed, Jan 23, 2013 at 10:41:54AM -0600, Edscott Wilson wrote: > I conclude this is a gtk memory leak. It occurs when calling > gtk_combo_box_new_with_entry(), Apparently, when the dialog that contains > the combo box is destroyed, the GList "visible_children" in file > gtkcombobox.c is not being cleansed of the pointer to the child widget, > entry. The leak does not occur if plain gtk_combo_box_new() is used > instead. Correct me if I'm wrong. Whether gtk_combo_box_get_path_for_child() can be called with a visible child different from those enumerated there (the only way a leak can occur) I cannot tell. In any case, any suspected leak that goes through GSlice should be first reproduced with G_SLICE=always-malloc -- and you find it real, a bug report is much better than suppression... Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
hi; On 22 January 2013 23:32, Edscott Wilson wrote: > Would the following be a leak in the gtk library (which I should not worry > about), or a leak in my program ( http://xffm.org )? have you read this page: https://live.gnome.org/Valgrind and used the environment variables required to get proper valgrind traces? ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
2013/1/23 David Nečas > > Whether gtk_combo_box_get_path_for_child() can be called with a visible > child different from those enumerated there (the only way a leak can > occur) I cannot tell. > > In any case, any suspected leak that goes through GSlice should be first > reproduced with G_SLICE=always-malloc -- and you find it real, a bug > report is much better than suppression... > > I did use G_SLICE=always-malloc. Strange thing is that on another program (rodent-fgr) there is no leak with the creation of combobox with entry. The only difference is that in rodent-fgr, all work is done by the main thread and the combobox is in the main window, while in rodent, the work is invoked from a non-main thread by means of a g_main_context_invoke() and the combobox is in a dialog. Maybe it's just a bug in Valgrind... I'm finding that a threaded environment may confuse Valgrind. I'll do some more checking. Edscott ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Would this leak be inside gtk?
On Wed, Jan 23, 2013 at 1:38 PM, Edscott Wilson < edscott.wilson.gar...@gmail.com> wrote: > Maybe it's just a bug in Valgrind... I'm finding that a threaded > environment may confuse Valgrind. I'll do some more checking. > In Valgrind threads become serialized, there is no true concurrency. I found a lot more success hunting memory leaks using Google's tcmalloc library. To use the heapcheck feature, you'll need to run your program on a x86 platform (a VM x86 on x86_64 works). tcmalloc on x86_64 does not provide the requisite stack traces. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list