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
