Peter Rabbitson wrote:
> Sorry for not writing earlier, had some other things to take care of.

I must be getting blind. Where have the big leaks gone? Only one
instance of a something over 100k, and that's a dubious 'still
reachable'. And all messages from valgrind seem to come from the server
code, *not* the imap code (anymore). I may be biased, but I would be
shocked if my patch from yesterday hadn't made a difference. We were
leaking in the GList handling.

And yes, we should also get rid of the messages originating in the
server code dealing but that is not on my critical path for 2.2.x. That
code is already destined for major overhaul in 2.3.x


> 
> Here is the next round of test results. As mentioned in the previous
> email, 6 tests are performed with 1000 2000 and 3000 messages, each with
>  and without G_DEBUG="always_malloc". Memory consumption is logged to
> memlog.* and is consistent regardless of the use of the allocator. These
> results are obtained from rev 2579 with the addition of Leif's patch as
> follows:
> 
> Index: dbmail-mailbox.c
> ===================================================================
> --- dbmail-mailbox.c    (revision 2579)
> +++ dbmail-mailbox.c    (working copy)
> @@ -1313,7 +1313,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;
> @@ -1330,12 +1330,13 @@
>         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(g_list_first(ids));
> +               //g_list_free(g_list_first(ids));
> +               g_list_free(topids);
>         } else {
>                 lo = 1;
>                 hi = g_tree_nnodes(self->ids);
> 
> 
> The valgrind logs and the memory consumption logs are here:
> http://rabbit.us/pool/misc/bug584_memcheck_svn2579_LJpatch_6xTests.tar.bz2
> 
> If you need the corresponding dbmail.err level 5 logs they are here:
> http://rabbit.us/pool/misc/bug584_memcheck_svn2579_LJpatch_6xTests_full.tar.bz2
> Be careful as this 3MB file expands to a whopping 170(!)MB
> 
> Also if further testing is necessary let me know which of the 6 tests
> are most descriptive, as running the whole thing takes about 2 hours here.
> 
> Peter
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> 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
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Reply via email to