Disregard this. It appears it is all calloc glib stuff and no more memory leaks exist that I can find in dbmail-pop3d or dbmail-imapd, one issue for paul to see if it is just me tho is the testimap.py script the testSetacl doesn't seem to complete when running in network mode, it does work however in stream mode, I found what I did wrong before that made it fail.
Thanks, Leif p.s. Maybe we will see 2.1.4 tomarrow? :) On Wed, March 1, 2006 1:50 am, Leif Jackson wrote: > Aaron, > > > Maybe I spoke too soon just checked out svn rev 2000 and took at look I > think you got the main issues with build_args, but I am curious are you > running valgrind via the testimap.py? As it seems there might be a few > more issues it is finding that you didn't see, I will check and send a > patch if I can resolve them or a updated dbmail.supp if they are glib > related. > > Thanks! > > > -leif > > > On Wed, March 1, 2006 1:32 am, Leif Jackson wrote: > >> On Wed, March 1, 2006 1:03 am, Aaron Stone wrote: >> >> >>> On Tue, 2006-02-28 at 19:02 -0500, Leif Jackson wrote: >>> >>> >>> >>>> On Tue, February 28, 2006 5:54 pm, Leif Jackson wrote: >>>> >>>> >>>> >>>>> >>>>> I belive I have come up with a fix for this and I have also found >>>>> a few extra possible memory leaks, I will submit a patch for your >>>>> review here in a bit >>>> >>>> what i tried didn't quite workout right so Aaron if you have some >>>> ideas go for it I will keep hacking as well, but I have to get back >>>> to another project. >>> >>> The use of g_strfreev here (ironically, for the out-of-memory cases) >>> is unsafe because strfreev tries to free the array itself -- but >>> the_args is static! So I replaced that with a little function to do >>> the same, and do it at the top of every call to build_args_array_ext. >>> The only leak >>> left appears to be this: >>> >>> ==23026== >>> 843 bytes in 12 blocks are definitely lost in loss record 16 of 23 >>> at 0x1B905E6A: calloc (vg_replace_malloc.c:176) by 0x1BA5FE1E: >>> g_malloc0 (in /usr/lib/libglib-2.0.so.0.800.5) >>> by 0x804D8A9: IMAPClientHandler (imap4.c:269) by 0x1B9475EB: >>> manage_start_cli_server (serverchild.c:373) by 0x1B94613C: >>> StartCliServer >>> (server.c:102) >>> by 0x8055270: main (imapd.c:119) >>> >>> The best I can figure is that it's leaking a list, because the only >>> line of code in all of DBMail that calls g_malloc0 is dm_list_nodeadd. >>> >> >> >> Cool!, I doub't this is an accual leak now, as the calloc calls from >> glib don't agree with valgrind, that is why they are supressed in my >> dbmail.supp file. Is the size always the same? I suspect it is and we >> are now in my opinion ready for 2.1.4 :)! >> >> Thanks, >> Leif >> >> >> >> >>> >>> Aaron >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> > > > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >
