I belive I have found the memleak for Peters issue:

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
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Reply via email to