Leif Jackson wrote:
> I belive I have found the memleak for Peters issue:
It's one instance of a whole class of leakage we uncovered here over the
last few days.
Before I did:
g_list_foreach(somelist, (GFunc)g_free, NULL);
g_list_free(somelist);
wheras we should always feed the head of the list to such calls:
somelist = g_list_first(somelist);
g_list_foreach(somelist, (GFunc)g_free, NULL);
somelist = g_list_first(somelist);
g_list_free(somelist);
which can be optimized by storing a reference to the start of the list
like you do below.
I've just committed a patch that adds the rewind to all instances of
freeing lists.
>
>
> Index: dbmail-mailbox.c
> ===================================================================
> --- dbmail-mailbox.c (revision 2574)
> +++ dbmail-mailbox.c (working copy)
> @@ -1312,7 +1312,7 @@
>
> GTree * dbmail_mailbox_get_set(struct DbmailMailbox *self, const char
> *set, gboolean uid)
> {
> - GList *ids = NULL, *sets = NULL;
> + GList *topids, *ids = NULL, *sets = NULL;
> GString *t;
> char *rest;
> u64_t i, l, r, lo = 0, hi = 0;
> @@ -1329,12 +1329,12 @@
> TRACE(TRACE_DEBUG,"[%s] uid [%d]", set, uid);
>
> if (uid) {
> - ids = g_tree_keys(self->ids);
> - ids = g_list_last(ids);
> + topids = g_tree_keys(self->ids);
> + ids = g_list_last(topids);
> hi = *((u64_t *)ids->data);
> - ids = g_list_first(ids);
> + ids = g_list_first(topids);
> lo = *((u64_t *)ids->data);
> - g_list_free(ids);
> + g_list_free(topids);
> } else {
> lo = 1;
> hi = g_tree_nnodes(self->ids);
>
> It is so small a leak it was not notices but peter's imapsync is doing a
> uid ic_fetch on hundreds of ids per fetch command over and over so the
> glist of ids leak would build and build on our servers but on his it
> goes nuts! :)
>
> Thanks,
> Leif
>
> p.s. Peter I am having trouble getting your test script to run on my dev
> box please try the change above and let me/ the group know.
>
>
> Peter Rabbitson wrote:
>> Paul J Stevens wrote:
>>
>>>> ==1631== 71,603,456 bytes in 288,752 blocks are still reachable in loss
>>>> record 26 of 26
>>>>
>>> This could be a side effect of the slab allocator. Use
>>> G_DEBUG=always_malloc valgrind ... to circumvent the glib default
>>> allocator.
>>>
>>
>> Tested with 'export G_DEBUG=always_malloc' yielding nearly identical
>> results (71,604,456 bytes this time). New logs at
>> http://rabbit.us/pool/misc/dbmail_bug584_memcheck_svn2574_always_malloc.tar.bz2
>>
>>
>>
>>> This URL has some interesting points
>>> http://www.tinymail.org/trac/tinymail/wiki/MemoryStats
>>>
>>
>> Erm, being a n00b and all, wouldn't this affect both imap daemons
>> involved in the test? In my case only 'host2' leaks, 'host1' stabilizing
>> at about 40M VSZ.
>>
>> Peter
>> _______________________________________________
>> Dbmail-dev mailing list
>> [email protected]
>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
