GNOME.org
 

Re: Trouble With Gtk(Dialog) Memory Management

Hi;

On 3 August 2016 at 17:54, Jonas <legojonas gmx de> wrote:


Thanks for the info about the slice allocator, I think that'll be good
for my purposes. As for valgrind and the suppression files, I tried a
few, it's too bad that it's hard to differentiate between actual memory
leaks and the ones that valgrind shows as leaks... Do you have any
other suppression file that might do a good job?


The link to the email thread I gave you should have more information
on suppression files.

Ciao,
 Emmanuele.


On Wed, 2016-08-03 at 15:48 +0100, Emmanuele Bassi wrote:

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.ht
ml)
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/msg000
00.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]