GNOME.org
 

Re: Trouble With Gtk(Dialog) Memory Management

Hi;

On 3 August 2016 at 15:37, Jonas <legojonas gmx de> wrote:

Hello Emmanuele,

I reran my code, looked a bit at the archives (especially your answer
to a question about a potential memory leak of gtk_widget_destroy()
https://mail.gnome.org/archives/gtk-list/2008-September/msg00108.html)
and here's where I am now:
- not only the test program for the dialog increases in memory usage
over time but also the one for the window. I assume this is because
they're both toplevel.


Yep.


- since I don't think that my code is faulty, is it correct to assume
that the GSlice allocator simply doesn't really release the memory I
requested until the end of program runtime?


The slice allocator will reuse freed slices of memory, if it can. If
you keep allocating stuff in a tight loop it may end up with a larger
slice of allocated memory before going back into the available slices
and recycle the memory.

That's why I said that top is not a memory measurement tool. If you
want to check for leaks, use Valgrind — and read these links before
doing that:

  * https://wiki.gnome.org/Valgrind
  * https://mail.gnome.org/archives/gtk-devel-list/2016-August/msg00000.html

Ciao,
 Emmanuele.


On Wed, 2016-08-03 at 12:44 +0100, Emmanuele Bassi wrote:

Hi;

you should probably search the archives of this very mailing list, as
this question has been asked countless times.

The tl;dr is:

 * GObject uses a slab allocator, not the system one
 * top is not a memory profiling tool
 * if you keep things running in a tight loop you don't give GTK any
chance to actually release memory
 * gtk_widget_destroy() is not the equivalent of free()

Ciao,
 Emmanuele.


On 3 August 2016 at 12:24, Jonas <legojonas gmx de> wrote:

Hello everyone,

I have a question about a memory leak I seem to have with
GtkDialog. I
already posted this on DreaminCode (username Progammer) and decided
to
ask the same question on the mailing lists here. Here it is:

"[...]I looked at the Gtk and GObject Documentation and figured out
the
following from Gtk Common Question 1.5, GObject Manual and the
gtk_widget_destroy() documentation:

- GtkWidgets that are top-level windows are created with an initial
floating reference count of one, Gtk calls g_object_ref_sink() to
acquire the reference and keeps the window in its list of top
-levels.
- all other GtkWidgets (e.g. buttons) are created with a floating
reference count of one. Packing the widget into a container makes
the
container own the reference (the container calls g_object_ref_sink
on
the widget). Simply calling g_object_ref_sink on your own makes
your
own code acquire the initial reference.
- destroying widgets: gtk_widget_destroy breaks references the
widget
holds to other widgets, packed widgets are removed from their
containers (decrementing the widget's reference count) and top
-level
windows are removed from Gtks list of top-levels (also decrementing
the
reference count).
- when the reference count of an object drops to 0, the object is
finalized and it's memory is freed
- GtkWindow is a GtkWidget is a GInitiallyUnowned is a GObject
(shortened hierarchy)

I wrote the following three programs to demonstrate memory
management
of GtkButton, GtkWindow and GtkDialog:
-- as far as I see it, GtkDialog is derived from GtkWindow and is
therefore a top-level and kept in Gtks list of top-levels. Please
correct me if I'm wrong ;) --

GtkButton:

#include <gtk/gtk.h>

int main (int argc, char *argv[])
{
    gtk_init( &argc, &argv );

    GtkWidget *button;
    do
    {
        button = gtk_button_new();  //create with floating ref
count of
one
        g_object_ref_sink(button);  //acquire the initial floating
reference (ref count is now 0 and non-floating)
        gtk_widget_destroy(button); //break external references
        g_object_unref(button);     //release my reference
(reference
count drops to 0, the widget's memory is freed)
        printf("Destroyed\n");
    }
    while(getchar() != 'Q');

    return 0;
}


GtkWindow:

#include <gtk/gtk.h>

int main (int argc, char *argv[])
{
    gtk_init( &argc, &argv );

    GtkWidget *window;
    do
    {
        window = gtk_window_new(GTK_WINDOW_TOPLEVEL);  //create
window,
gtk will add it to it's list of top-levels and acquire ownership of
the
initial reference.
        gtk_widget_destroy(window);   //break references the window
holds to other objects, remove window from gtk's list of toplevels.
Window is finalized (memory is freed).
        printf("Destroyed\n");
    }
    while(getchar() != 'Q');

    return 0;
}

GtkDialog:

#include <gtk/gtk.h>

int main (int argc, char *argv[])
{
    gtk_init( &argc, &argv );

    GtkWidget *dialog;
    do
    {
        dialog = gtk_dialog_new();     //create dialog, add to list
of
top-levels
        gtk_widget_destroy(dialog);    //break references it holds,
remove from list of top-levels, finalizing dialog and freeing
memory (I
thought :D)
        printf("Destroyed\n");
    }
    while(getchar() != 'Q');

    return 0;
}


For all three programs, a widget is created and destroyed and when
the
user hits the Return key and 'Q' was not pressed right before, it's
done again.

What I expected to happen:
- Memory usage of all three programs should stay the same even when
I
hit the Return key a hundred to a thousand times or more.

What really happened:
- the memory usage did not go up for the program with the GtkButton
and
the program with the GtkWindow.
- for the program with the GtkDialog, the memory usage went up
every
time I hit the return key.

Why is this happening? I thought GtkDialog would behave the same as
GtkWindow in terms of memory management since it's derived from it.

I hope anyone knows what is going on here :)" - Progammer on
http://www
.dreamincode.net/forums/topic/395882-trouble-with-gtkdialog-memory
-management/ (August 3rd 2016, 11:23 GMT)


Does anyone of you know why this is?

Jonas Fuglsang-Petersen
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list








-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]