Here i go again.... checked dbmail-lmtpd and it has 2 minor problems:

first:

--- dbmail-svn-2.1.3-2000.orig/lmtp.c   2006-03-01 01:46:40.939279000 -0500
+++ dbmail-svn-2.1.3-2000.new/lmtp.c    2006-03-01 03:45:56.648141000 -0500
@@ -476,6 +476,8 @@
           if (goodtogo) {
            /* Sure fine go ahead. */
            dm_list_nodeadd(&from, tmpaddr, strlen(tmpaddr)+1);
+           /* free tmpaddr as dm_list_nodeadd makes a copy */
+           dm_free(tmpaddr);
            ci_write((FILE *) stream,
                     "250 Sender <%s> OK\r\n",
                    (char *)(dm_list_getstart(&from)->data));

Simple fix but an issue none the less. Then there is the 2nd one....

in lmtp.c around line 516:

/* find_bounded() allocated tmpaddr for us, and that's ok
 * since dsnuser_free() will free it for us later on. */
dsnuser.address = tmpaddr;

but the comment isn't true thus this leaks ? What do you guys want to do
with this?

void dsnuser_free(deliver_to_user_t * dsnuser)
{
   dsnuser->useridnr = 0;
   dsnuser->dsn.class = 0;
   dsnuser->dsn.subject = 0;
   dsnuser->dsn.detail = 0;

   /* These are nominally const, but
    * we really do want to free them. */
   /*
   dm_free((char *) dsnuser->address);
   dm_free((char *) dsnuser->mailbox);
   */
   dsnuser->address = NULL;
....


Thanks,
Leif


p.s. fix these 2 minor issues and then rel 2.1.4 :) blah..blah just my .02
as always.



On Wed, March 1, 2006 3:09 am, Leif Jackson wrote:
> 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
>>>> 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
>>
>>
>>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>


Reply via email to