Re: [Evolution-hackers] Possible memory leak

2008-01-15 Thread Jose Dapena Paz
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 =

Re: [Evolution-hackers] Possible memory leak

2008-01-14 Thread Philip Van Hoof
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

Re: [Evolution-hackers] Possible memory leak

2008-01-14 Thread Matthew Barnes
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 with

Re: [Evolution-hackers] Possible memory leak

2008-01-13 Thread Philip Van Hoof
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