Paul,
I am not sure that the g_mime_init and shutdown moving to the session
is a good idea? Once/ If dbmail ever goes threaded this won't work as it
would only need it in the main function and since g_mime uses a global
object can we assume that each session will be only on one forked imapd
instance? If not I supsect g_mime_init and shutdown in the session will
cause untold problems.
Just my .02
Thanks,
Leif
Paul J Stevens wrote:
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
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
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
