El lun, 14-01-2008 a las 14:33 +0100, Philip Van Hoof escribió:
> I think this needs to be something like this:
>
> GSList *item = cc->status_stack;
> cc->status_stack = g_slist_remove_link(cc->status_stack, item);
> g_slist_free (item);
Or just use g_slist_delete_link:
cc->status_stack = g_sl
On Tue, 2008-01-15 at 11:55 +0100, Jose Dapena Paz wrote:
> El lun, 14-01-2008 a las 14:33 +0100, Philip Van Hoof escribió:
>
> > I think this needs to be something like this:
> >
> > GSList *item = cc->status_stack;
> > cc->status_stack = g_slist_remove_link(cc->status_stack, item);
> > g_slist
On Mon, 2008-01-14 at 14:33 +0100, Philip Van Hoof wrote:
> I think I've found the leak ...
>
> g_slist_remove_link:
>
> Removes an element from a GSList, without freeing the element. The
> removed element's next link is set to NULL, so that it becomes a
> self-contained list
I think I've found the leak ...
g_slist_remove_link:
Removes an element from a GSList, without freeing the element. The
removed element's next link is set to NULL, so that it becomes a
self-contained list with one element.
Notice the "without freeing the element"
Yet
void
On Mon, 2008-01-14 at 01:47 +0100, Philip Van Hoof wrote:
> I have this memory analysis tool that I'm willing to believe that tells
> me this line in camel-folder.c causes 381 times a leaked allocation of
> in total 5.95 kb. (I opened one folder of 1000 items). It seems to be
> the g_slice_alloc
Hi there,
I have this memory analysis tool that I'm willing to believe that tells
me this line in camel-folder.c causes 381 times a leaked allocation of
in total 5.95 kb. (I opened one folder of 1000 items). It seems to be
the g_slice_alloc (which does a malloc since I disabled gslice) of the
g_h
