Re: Would this leak be inside gtk?

2013-01-25 Thread Edscott Wilson 
I've just verified with tcmalloc that there is no leak in
gtk_combo_box_new_with_entry(), on x86. The issue is with Valgrind which
gets confused with concurrent threads.  Although the spaguetti output pprof
is a bit confusing at first, once you look through the documentation the
diagrams are very helpful.

Issue solved.

Thanks.

2013/1/23 Andrew Potter 

> 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
>
___
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-01-23 Thread Andrew Potter 
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

Re: Would this leak be inside gtk?

2013-01-23 Thread Edscott Wilson 
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?

2013-01-23 Thread Emmanuele Bassi 
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-01-23 Thread David Nečas 
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?

2013-01-23 Thread Edscott Wilson 
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

Would this leak be inside gtk?

2013-01-22 Thread 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