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 f
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=a
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
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
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 oc
