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