Re: GTK free function doesn't appear to have any affect.



On Sun, 16 Jun 2013 12:28:52 +0530
dE <de techno gmail com> wrote:
Apart from that, in the free_ptr? Does memory get freed for anyone
else?

#include <stdio.h>
#include <gtk/gtk.h>
#define COLS 200
void free_ptr ( GtkListStore * );

int main (  ) {
     gtk_init( NULL, NULL );
     int i, j;
     char *temp;
     GtkTreeIter current;
     GType *str_type = g_malloc (sizeof (GType) * COLS);
     for (i = 0; i < COLS; i++)
         str_type [i] = G_TYPE_STRING;
     GtkListStore *store = gtk_list_store_newv (COLS, str_type);
     g_free (str_type);
     for (i = 0; i < 300000 ; i++) {
         gtk_list_store_append ( store, &current );
         for ( j = 0 ; j < COLS ; j++ ) {
             gtk_list_store_set ( store , &current , j , "Hello world 
Hello world Hello world!", -1 );
         }
     }
     printf ( "freeing after 10 seconds\n" );
     sleep (10);
     free_ptr ( store );
     printf ("Now freed\n");
     sleep (10);
     return 0;
}

void free_ptr ( GtkListStore *store ) {
     gtk_list_store_clear (store);
     g_object_unref( G_OBJECT (store) );
}

You should compile your code with warnings enabled.  Then you would
find out other things about your code (namely that 'temp' is not used).
Apart from that, technically the code is OK and it does destroy the
list store correctly.

Turning to the main point, the thing about your code is that it is
inadequate for detecting memory leakage, because it does not take
account of caching.  To come up with a meaningful test, you need to
rerun the memory-using code more than once in the program.  If you do
so, you will find that on each run other than the first, memory usage
does not increase.  From this I deduce (I hope) that list stores cache
the memory allocated to individual records for reuse. Presumably that
is thought to be an optimization for most uses.  In the pathological
case of a list store with 300000 x 300 cells holding allocated strings
that clearly is not the case, but a list store with so many cells would
be unusably slow anyway when used in conjunction with a tree view.

There are various additional things you can do to check memory usage:
see https://developer.gnome.org/glib/2.36/glib-running.html .

For those kinds of pathological cases, you probably need to write your
own tree model which does things the way you want them.

Chris


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]