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 agpot...@gmail.com

 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 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 edscott.wilson.gar...@gmail.com


 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?

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 Emmanuele Bassi 
hi;

On 22 January 2013 23:32, Edscott Wilson
edscott.wilson.gar...@gmail.com 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 Edscott Wilson 
2013/1/23 David Nečas y...@physics.muni.cz


 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 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

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