Mailing List Archive

All,

I found one ting this breaks I will send a patch shortly.. Bascialy
bounce.c uses the config as a global. I don't see that this is a great
idea? I will be moving:
field_t dbmail_from_address, sendmail, postmaster;

to be global instead, so I can still FreeConfig in the main function.

Thanks,
Leif


> Cool,
>
> Ilja, I have attached a patch that adds a FreeConfig function, this
> doesn't solve my memory leaks from list.c addnode, but makes it a lot
> easier to debug as it free's the config list's right after their used
> instead of at the end of the main (). Please commit it to cvs if you feel
> it warrants it.
>
> Thanks,
> leif
>
>
>> I've put the patch in CVS, because we'll need it anyway. This way, it's
>> also easier to debug it, because a simple cvs update will get everybody
>> the new code :)
>>
>> The delivery chain is still buggy: When delivering messages through
>> LMTP, all messages get delivered twice.
>>
>> Ilja
>>
>> Leif Jackson wrote:
>>
>>> Ilja & Aaron,
>>>
>>> I am looking for this patch. I cannot access it from sourceforge? Or
>>> do
>>> I
>>> have to checkout from cvs differently than the default dbmail root? I
>>> would be glad to look at this.... Also Aaron, i was working on your
>>> sieve
>>> code but there are some issues between the current libsieve you have in
>>> cvs and the last one posed on sourceforge, the api and the lib doesn't
>>> match quite right or at least not to the code you have in the dbmail
>>> cvs
>>> tree, i am really exited about this feature and would like to help.
>>>
>>> Thanks,
>>> Leif
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>don't know why, but I just cannot find the reason why the delivery
>>>>user_idnr is added to the userids-list in the dsn twice. It does not
>>>>happen when using dbmail-smtp, only when using dbmail-lmtp.
>>>>
>>>>Aaron (or anybody else), can you take a look at this? I'm completely
>>>>lost at the moment.. :(
>>>>
>>>>Also, there is the problem with the read_header() function. Some
>>>> testing
>>>>has revealed that it always functions the first time an instance of
>>>>dbmail-lmtp gets a message. The second time that the same instance of
>>>>the daemon gets a message, it reads the output from the MTA (postfix in
>>>>my case) very slowly. Are we forgetting to cleanup something?
>>>>
>>>>Ilja
>>>>
>>>>
>>>>Ilja Booij wrote:
>>>>
>>>>
>>>>>I haven't found the cause of this bug yet. There is also still a
>>>>> problem
>>>>>with the read_header() function. It's constantly hanging on an fgets
>>>>>there..
>>>>>
>>>>>Ilja
>>>>>
>>>>>Ilja Booij wrote:
>>>>>
>>>>>
>>>>>>There is no problem when sending messages through dbmail-smtp, only
>>>>>>when using lmtp. Strange..
>>>>>>
>>>>>>looking further
>>>>>>
>>>>>>Ilja
>>>>>>
>>>>>>Ilja Booij wrote:
>>>>>>
>>>>>>
>>>>>>>Now there's another problem with deliveries. I get every mail twice!
>>>>>>>
>>>>>>>I'm firing up gdb as I type..
>>>>>>>
>>>>>>>Ilja
>>>>>>>
>>>>>>>Aaron Stone wrote:
>>>>>>>
>>>>>>>
>>>>>>>>Posted to SourceForge. A little patch to pipe.c and header.c, which
>>>>>>>>fixes a
>>>>>>>>buffer boundary issue in the newline/rfc counting, the forgotten
>>>>>>>>delivery
>>>>>>>>useridnr loop and a missing rfcsize argument to sort_and_deliver.
>>>>>>>>
>>>>>>>>It's also a proper forwards patch now :-P
>>>>>>>>
>>>>>>>>Aaron
>>>>>>>>
>>>>>>>>
>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Excuses, excuses. See SourceForge for an updated version of the
>>>>>>>>>previously
>>>>>>>>>posted patch; I neglected to add the new rfcsize arguments to the
>>>>>>>>>sort call,
>>>>>>>>>and something else gone wrong read_header(). Valgrinding as we
>>>>>>>>>speak!
>>>>>>>>>
>>>>>>>>>Aaron
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Now I remember! I continued fixing a bug or two in the
>>>>>>>>>>2.0rc2-fixes-snap1
>>>>>>>>>>tree after I'd made the patches from it. But to start clean, I
>>>>>>>>>>took a fresh
>>>>>>>>>>2.0rc2, applied the patches, and then started working towards the
>>>>>>>>>>next set
>>>>>>>>>>of patches... apparently without bringing this bugfix into the
>>>>>>>>>> new
>>>>>>>>>>tree :-\
>>>>>>>>>>
>>>>>>>>>>I read over the rest of the diff to make sure that I didn't leave
>>>>>>>>>>anything
>>>>>>>>>>else out, and this does seem to be the only thing I missed.
>>>>>>>>>>
>>>>>>>>>>Apply the attached patch, *reversed* (because I really need sleep
>>>>>>>>>>:-P)
>>>>>>>>>>
>>>>>>>>>>Aaron
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>""Aaron Stone"" <aaron@serendipity.palo-alto.ca.us> said:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Oh, weird. I really did fix that already; I'll see if maybe I
>>>>>>>>>>>fixed it in an
>>>>>>>>>>>older tree by accident. Will post a patch this afternoon.
>>>>>>>>>>>
>>>>>>>>>>>Aaron
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>I've applied the patch (have not updated CVS yet).
>>>>>>>>>>>>
>>>>>>>>>>>>I ran into the following problem:
>>>>>>>>>>>>When delivering a message, all message go into the mailbox of
>>>>>>>>>>>>user_idnr 0 (that is: zero).
>>>>>>>>>>>>
>>>>>>>>>>>>The problem seems to be, that the user_idnrs to deliver the
>>>>>>>>>>>>messages to are kept in delivery->userids (in a list), but that
>>>>>>>>>>>>this list is never used when attempting delivery. The
>>>>>>>>>>>>delivery->userids field is not used when calling
>>>>>>>>>>>>sort_and_deliver(). In that call, only delivery->useridnr is
>>>>>>>>>>>>used, which defaults to zero.
>>>>>>>>>>>>
>>>>>>>>>>>>Ilja
>>>>>>>>>>>>
>>>>>>>>>>>>Aaron Stone wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Here it goes... I'll also post to SourceForge.
>>>>>>>>>>>>>
>>>>>>>>>>>>>Aaron
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>HEAD is completely updated. I'm having some trouble updating
>>>>>>>>>>>>>>dbmail_2_0_branch, due to conflicts when applying patches. I
>>>>>>>>>>>>>>guess I'll wait with updating that branch. Or, like somebody
>>>>>>>>>>>>>>suggested a while
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>ago,
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>do the branching on release of 2.0 final (and abandon the
>>>>>>>>>>>>>>current
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>branch
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>for now).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Good luck finishing your project :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Ilja
>>>>>>>>>>>>>>Aaron Stone wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>If you have CVS updated to your latest working tree I'll
>>>>>>>>>>>>>>> patch
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>against it
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>in a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>>few hours. This moment I have to finish up a project before
>>>>>>>>>>>>>>>daybreak.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Aaron
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Just tried this for myself. A lot of warnings..
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I guess the cleaned up statements are in the patches you'll
>>>>>>>>>>>>>>>>send me today? ;)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I agree we should keep the __attribute__ thing in the
>>>>>>>>>>>>>>>>source. It does not cost us anything, and it helps
>>>>>>>>>>>>>>>>preventing bugs. Sounds like free lunch to me! :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Ilja
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Aaron Stone wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Well that was fun! I also caught three or four more of the
>>>>>>>>>>>>>>>>>missing
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>comma
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>>>>errors, and a handful of "%s, %s: ...." formats that were
>>>>>>>>>>>>>>>>>missing the
>>>>>>>>>>>>>>>>>__FILE__, __FUNCTION arguments.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>I cleaned up all of the warnings, though we should
>>>>>>>>>>>>>>>>>definitely keep
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>the GNU
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>>>attribute in the source to warn against format bugs in the
>>>>>>>>>>>>>>>>>future.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>Aaron
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>I found the GNU extension to turn on pritnf style format
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>checking! In
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>debug.h,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>make this your declaration of trace():
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>void trace(int level, char *formatstring, ...)
>>>>>>>>>>>>>>>>>> __attribute__((format(printf, 2, 3)));
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>Voila, tons of errors next time you make.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>--
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>--
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>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
>>>>
>>>>_______________________________________________
>>>>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
>>
>

Attached is the new patch with the slight change I figured for now the
easiest was to just move the FreeConfig for the smtpItems to the end of
freeall:, well maybe we want to think about a struct for these items that
can be global instead of the listnodes, *shrug* let me know.

Thanks,
Leif

p.s. I belive after a lopng bout of checks with valgrind ( an amazing
package for many reasons) that the memory leaks if any are only in the
main function of pop3, as far as I can tell imapd is clean! :)

p.p.s. I have started on server side sorting code, may have something by
this weekend I can share. has ISCS thought about or started any similar
code before I get to far into it? thx.

> All,
>
> I found one ting this breaks I will send a patch shortly.. Bascialy
> bounce.c uses the config as a global. I don't see that this is a great
> idea? I will be moving:
> field_t dbmail_from_address, sendmail, postmaster;
>
> to be global instead, so I can still FreeConfig in the main function.
>
> Thanks,
> Leif
>
>
>> Cool,
>>
>> Ilja, I have attached a patch that adds a FreeConfig function, this
>> doesn't solve my memory leaks from list.c addnode, but makes it a lot
>> easier to debug as it free's the config list's right after their used
>> instead of at the end of the main (). Please commit it to cvs if you
>> feel
>> it warrants it.
>>
>> Thanks,
>> leif
>>
>>
>>> I've put the patch in CVS, because we'll need it anyway. This way, it's
>>> also easier to debug it, because a simple cvs update will get everybody
>>> the new code :)
>>>
>>> The delivery chain is still buggy: When delivering messages through
>>> LMTP, all messages get delivered twice.
>>>
>>> Ilja
>>>
>>> Leif Jackson wrote:
>>>
>>>> Ilja & Aaron,
>>>>
>>>> I am looking for this patch. I cannot access it from sourceforge? Or
>>>> do
>>>> I
>>>> have to checkout from cvs differently than the default dbmail root? I
>>>> would be glad to look at this.... Also Aaron, i was working on your
>>>> sieve
>>>> code but there are some issues between the current libsieve you have
>>>> in
>>>> cvs and the last one posed on sourceforge, the api and the lib doesn't
>>>> match quite right or at least not to the code you have in the dbmail
>>>> cvs
>>>> tree, i am really exited about this feature and would like to help.
>>>>
>>>> Thanks,
>>>> Leif
>>>>
>>>>

I'm really confused about what's being freed... I haven't been seeing any
other memory leaks from dbmail-smtp except for MySQL's internal allocations.

Aaron


""Leif Jackson"" <ljackson@jjcons.com> said:

> All,
>
> I found one ting this breaks I will send a patch shortly.. Bascialy
> bounce.c uses the config as a global. I don't see that this is a great
> idea? I will be moving:
> field_t dbmail_from_address, sendmail, postmaster;
>
> to be global instead, so I can still FreeConfig in the main function.
>
> Thanks,
> Leif
>
>
> > Cool,
> >
> > Ilja, I have attached a patch that adds a FreeConfig function, this
> > doesn't solve my memory leaks from list.c addnode, but makes it a lot
> > easier to debug as it free's the config list's right after their used
> > instead of at the end of the main (). Please commit it to cvs if you feel
> > it warrants it.
> >
> > Thanks,
> > leif
> >
> >
> >> I've put the patch in CVS, because we'll need it anyway. This way, it's
> >> also easier to debug it, because a simple cvs update will get everybody
> >> the new code :)
> >>
> >> The delivery chain is still buggy: When delivering messages through
> >> LMTP, all messages get delivered twice.
> >>
> >> Ilja
> >>
> >> Leif Jackson wrote:
> >>
> >>> Ilja & Aaron,
> >>>
> >>> I am looking for this patch. I cannot access it from sourceforge? Or
> >>> do
> >>> I
> >>> have to checkout from cvs differently than the default dbmail root? I
> >>> would be glad to look at this.... Also Aaron, i was working on your
> >>> sieve
> >>> code but there are some issues between the current libsieve you have in
> >>> cvs and the last one posed on sourceforge, the api and the lib doesn't
> >>> match quite right or at least not to the code you have in the dbmail
> >>> cvs
> >>> tree, i am really exited about this feature and would like to help.
> >>>
> >>> Thanks,
> >>> Leif
> >>>
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>don't know why, but I just cannot find the reason why the delivery
> >>>>user_idnr is added to the userids-list in the dsn twice. It does not
> >>>>happen when using dbmail-smtp, only when using dbmail-lmtp.
> >>>>
> >>>>Aaron (or anybody else), can you take a look at this? I'm completely
> >>>>lost at the moment.. :(
> >>>>
> >>>>Also, there is the problem with the read_header() function. Some
> >>>> testing
> >>>>has revealed that it always functions the first time an instance of
> >>>>dbmail-lmtp gets a message. The second time that the same instance of
> >>>>the daemon gets a message, it reads the output from the MTA (postfix in
> >>>>my case) very slowly. Are we forgetting to cleanup something?
> >>>>
> >>>>Ilja
> >>>>
> >>>>
> >>>>Ilja Booij wrote:
> >>>>
> >>>>
> >>>>>I haven't found the cause of this bug yet. There is also still a
> >>>>> problem
> >>>>>with the read_header() function. It's constantly hanging on an fgets
> >>>>>there..
> >>>>>
> >>>>>Ilja
> >>>>>
> >>>>>Ilja Booij wrote:
> >>>>>
> >>>>>
> >>>>>>There is no problem when sending messages through dbmail-smtp, only
> >>>>>>when using lmtp. Strange..
> >>>>>>
> >>>>>>looking further
> >>>>>>
> >>>>>>Ilja
> >>>>>>
> >>>>>>Ilja Booij wrote:
> >>>>>>
> >>>>>>
> >>>>>>>Now there's another problem with deliveries. I get every mail twice!
> >>>>>>>
> >>>>>>>I'm firing up gdb as I type..
> >>>>>>>
> >>>>>>>Ilja
> >>>>>>>
> >>>>>>>Aaron Stone wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>>Posted to SourceForge. A little patch to pipe.c and header.c, which
> >>>>>>>>fixes a
> >>>>>>>>buffer boundary issue in the newline/rfc counting, the forgotten
> >>>>>>>>delivery
> >>>>>>>>useridnr loop and a missing rfcsize argument to sort_and_deliver.
> >>>>>>>>
> >>>>>>>>It's also a proper forwards patch now :-P
> >>>>>>>>
> >>>>>>>>Aaron
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>Excuses, excuses. See SourceForge for an updated version of the
> >>>>>>>>>previously
> >>>>>>>>>posted patch; I neglected to add the new rfcsize arguments to the
> >>>>>>>>>sort call,
> >>>>>>>>>and something else gone wrong read_header(). Valgrinding as we
> >>>>>>>>>speak!
> >>>>>>>>>
> >>>>>>>>>Aaron
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>Now I remember! I continued fixing a bug or two in the
> >>>>>>>>>>2.0rc2-fixes-snap1
> >>>>>>>>>>tree after I'd made the patches from it. But to start clean, I
> >>>>>>>>>>took a fresh
> >>>>>>>>>>2.0rc2, applied the patches, and then started working towards the
> >>>>>>>>>>next set
> >>>>>>>>>>of patches... apparently without bringing this bugfix into the
> >>>>>>>>>> new
> >>>>>>>>>>tree :-\
> >>>>>>>>>>
> >>>>>>>>>>I read over the rest of the diff to make sure that I didn't leave
> >>>>>>>>>>anything
> >>>>>>>>>>else out, and this does seem to be the only thing I missed.
> >>>>>>>>>>
> >>>>>>>>>>Apply the attached patch, *reversed* (because I really need sleep
> >>>>>>>>>>:-P)
> >>>>>>>>>>
> >>>>>>>>>>Aaron
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>""Aaron Stone"" <aaron@serendipity.palo-alto.ca.us> said:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>Oh, weird. I really did fix that already; I'll see if maybe I
> >>>>>>>>>>>fixed it in an
> >>>>>>>>>>>older tree by accident. Will post a patch this afternoon.
> >>>>>>>>>>>
> >>>>>>>>>>>Aaron
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>I've applied the patch (have not updated CVS yet).
> >>>>>>>>>>>>
> >>>>>>>>>>>>I ran into the following problem:
> >>>>>>>>>>>>When delivering a message, all message go into the mailbox of
> >>>>>>>>>>>>user_idnr 0 (that is: zero).
> >>>>>>>>>>>>
> >>>>>>>>>>>>The problem seems to be, that the user_idnrs to deliver the
> >>>>>>>>>>>>messages to are kept in delivery->userids (in a list), but that
> >>>>>>>>>>>>this list is never used when attempting delivery. The
> >>>>>>>>>>>>delivery->userids field is not used when calling
> >>>>>>>>>>>>sort_and_deliver(). In that call, only delivery->useridnr is
> >>>>>>>>>>>>used, which defaults to zero.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Ilja
> >>>>>>>>>>>>
> >>>>>>>>>>>>Aaron Stone wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>Here it goes... I'll also post to SourceForge.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Aaron
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>HEAD is completely updated. I'm having some trouble updating
> >>>>>>>>>>>>>>dbmail_2_0_branch, due to conflicts when applying patches. I
> >>>>>>>>>>>>>>guess I'll wait with updating that branch. Or, like somebody
> >>>>>>>>>>>>>>suggested a while
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>ago,
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>do the branching on release of 2.0 final (and abandon the
> >>>>>>>>>>>>>>current
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>branch
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>for now).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Good luck finishing your project :)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>Ilja
> >>>>>>>>>>>>>>Aaron Stone wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>If you have CVS updated to your latest working tree I'll
> >>>>>>>>>>>>>>> patch
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>against it
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>in a
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>few hours. This moment I have to finish up a project before
> >>>>>>>>>>>>>>>daybreak.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Aaron
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Just tried this for myself. A lot of warnings..
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>I guess the cleaned up statements are in the patches you'll
> >>>>>>>>>>>>>>>>send me today? ;)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>I agree we should keep the __attribute__ thing in the
> >>>>>>>>>>>>>>>>source. It does not cost us anything, and it helps
> >>>>>>>>>>>>>>>>preventing bugs. Sounds like free lunch to me! :)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Ilja
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>Aaron Stone wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>Well that was fun! I also caught three or four more of the
> >>>>>>>>>>>>>>>>>missing
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>comma
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>>>>>>errors, and a handful of "%s, %s: ...." formats that were
> >>>>>>>>>>>>>>>>>missing the
> >>>>>>>>>>>>>>>>>__FILE__, __FUNCTION arguments.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>I cleaned up all of the warnings, though we should
> >>>>>>>>>>>>>>>>>definitely keep
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>the GNU
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>>>>>>attribute in the source to warn against format bugs in the
> >>>>>>>>>>>>>>>>>future.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>Aaron
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>I found the GNU extension to turn on pritnf style format
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>checking! In
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>debug.h,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>make this your declaration of trace():
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>void trace(int level, char *formatstring, ...)
> >>>>>>>>>>>>>>>>>> __attribute__((format(printf, 2, 3)));
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>Voila, tons of errors next time you make.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>--
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>--
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>_______________________________________________
> >>>>>>>>>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
> >>>>
> >>>>_______________________________________________
> >>>>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
>



--

The change was more to get the lists created for the configs out of the
way for my debugging, I like the idea of not keeping stuff around any
longer than it has to... The change doesn't fix any memory leak that i can
tell as I said in the first message. I just think it looks cleaner.
*shrug*

-leif

> I'm really confused about what's being freed... I haven't been seeing any
> other memory leaks from dbmail-smtp except for MySQL's internal
> allocations.
>
> Aaron
>
>
> ""Leif Jackson"" <ljackson@jjcons.com> said:
>
>> All,
>>
>> I found one ting this breaks I will send a patch shortly.. Bascialy
>> bounce.c uses the config as a global. I don't see that this is a great
>> idea? I will be moving:
>> field_t dbmail_from_address, sendmail, postmaster;
>>
>> to be global instead, so I can still FreeConfig in the main function.
>>
>> Thanks,
>> Leif
>>
>>
>> > Cool,
>> >
>> > Ilja, I have attached a patch that adds a FreeConfig function, this
>> > doesn't solve my memory leaks from list.c addnode, but makes it a lot
>> > easier to debug as it free's the config list's right after their used
>> > instead of at the end of the main (). Please commit it to cvs if you
>> feel
>> > it warrants it.
>> >
>> > Thanks,
>> > leif
>> >
>> >
>> >> I've put the patch in CVS, because we'll need it anyway. This way,
>> it's
>> >> also easier to debug it, because a simple cvs update will get
>> everybody
>> >> the new code :)
>> >>
>> >> The delivery chain is still buggy: When delivering messages through
>> >> LMTP, all messages get delivered twice.
>> >>
>> >> Ilja
>> >>
>> >> Leif Jackson wrote:
>> >>
>> >>> Ilja & Aaron,
>> >>>
>> >>> I am looking for this patch. I cannot access it from sourceforge?
>> Or
>> >>> do
>> >>> I
>> >>> have to checkout from cvs differently than the default dbmail root?
>> I
>> >>> would be glad to look at this.... Also Aaron, i was working on your
>> >>> sieve
>> >>> code but there are some issues between the current libsieve you have
>> in
>> >>> cvs and the last one posed on sourceforge, the api and the lib
>> doesn't
>> >>> match quite right or at least not to the code you have in the dbmail
>> >>> cvs
>> >>> tree, i am really exited about this feature and would like to help.
>> >>>
>> >>> Thanks,
>> >>> Leif
>> >>>
>> >>>
>> >>>
>> >>>>Hi,
>> >>>>
>> >>>>don't know why, but I just cannot find the reason why the delivery
>> >>>>user_idnr is added to the userids-list in the dsn twice. It does not
>> >>>>happen when using dbmail-smtp, only when using dbmail-lmtp.
>> >>>>
>> >>>>Aaron (or anybody else), can you take a look at this? I'm
>> completely
>> >>>>lost at the moment.. :(
>> >>>>
>> >>>>Also, there is the problem with the read_header() function. Some
>> >>>> testing
>> >>>>has revealed that it always functions the first time an instance of
>> >>>>dbmail-lmtp gets a message. The second time that the same instance
>> of
>> >>>>the daemon gets a message, it reads the output from the MTA (postfix
>> in
>> >>>>my case) very slowly. Are we forgetting to cleanup something?
>> >>>>
>> >>>>Ilja
>> >>>>
>> >>>>
>> >>>>Ilja Booij wrote:
>> >>>>
>> >>>>
>> >>>>>I haven't found the cause of this bug yet. There is also still a
>> >>>>> problem
>> >>>>>with the read_header() function. It's constantly hanging on an
>> fgets
>> >>>>>there..
>> >>>>>
>> >>>>>Ilja
>> >>>>>
>> >>>>>Ilja Booij wrote:
>> >>>>>
>> >>>>>
>> >>>>>>There is no problem when sending messages through dbmail-smtp,
>> only
>> >>>>>>when using lmtp. Strange..
>> >>>>>>
>> >>>>>>looking further
>> >>>>>>
>> >>>>>>Ilja
>> >>>>>>
>> >>>>>>Ilja Booij wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>>Now there's another problem with deliveries. I get every mail
>> twice!
>> >>>>>>>
>> >>>>>>>I'm firing up gdb as I type..
>> >>>>>>>
>> >>>>>>>Ilja
>> >>>>>>>
>> >>>>>>>Aaron Stone wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>>Posted to SourceForge. A little patch to pipe.c and header.c,
>> which
>> >>>>>>>>fixes a
>> >>>>>>>>buffer boundary issue in the newline/rfc counting, the forgotten
>> >>>>>>>>delivery
>> >>>>>>>>useridnr loop and a missing rfcsize argument to
>> sort_and_deliver.
>> >>>>>>>>
>> >>>>>>>>It's also a proper forwards patch now :-P
>> >>>>>>>>
>> >>>>>>>>Aaron
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>Excuses, excuses. See SourceForge for an updated version of the
>> >>>>>>>>>previously
>> >>>>>>>>>posted patch; I neglected to add the new rfcsize arguments to
>> the
>> >>>>>>>>>sort call,
>> >>>>>>>>>and something else gone wrong read_header(). Valgrinding as we
>> >>>>>>>>>speak!
>> >>>>>>>>>
>> >>>>>>>>>Aaron
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>>Now I remember! I continued fixing a bug or two in the
>> >>>>>>>>>>2.0rc2-fixes-snap1
>> >>>>>>>>>>tree after I'd made the patches from it. But to start clean, I
>> >>>>>>>>>>took a fresh
>> >>>>>>>>>>2.0rc2, applied the patches, and then started working towards
>> the
>> >>>>>>>>>>next set
>> >>>>>>>>>>of patches... apparently without bringing this bugfix into the
>> >>>>>>>>>> new
>> >>>>>>>>>>tree :-\
>> >>>>>>>>>>
>> >>>>>>>>>>I read over the rest of the diff to make sure that I didn't
>> leave
>> >>>>>>>>>>anything
>> >>>>>>>>>>else out, and this does seem to be the only thing I missed.
>> >>>>>>>>>>
>> >>>>>>>>>>Apply the attached patch, *reversed* (because I really need
>> sleep
>> >>>>>>>>>>:-P)
>> >>>>>>>>>>
>> >>>>>>>>>>Aaron
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>""Aaron Stone"" <aaron@serendipity.palo-alto.ca.us> said:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>Oh, weird. I really did fix that already; I'll see if maybe I
>> >>>>>>>>>>>fixed it in an
>> >>>>>>>>>>>older tree by accident. Will post a patch this afternoon.
>> >>>>>>>>>>>
>> >>>>>>>>>>>Aaron
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>I've applied the patch (have not updated CVS yet).
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>I ran into the following problem:
>> >>>>>>>>>>>>When delivering a message, all message go into the mailbox
>> of
>> >>>>>>>>>>>>user_idnr 0 (that is: zero).
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>The problem seems to be, that the user_idnrs to deliver the
>> >>>>>>>>>>>>messages to are kept in delivery->userids (in a list), but
>> that
>> >>>>>>>>>>>>this list is never used when attempting delivery. The
>> >>>>>>>>>>>>delivery->userids field is not used when calling
>> >>>>>>>>>>>>sort_and_deliver(). In that call, only delivery->useridnr is
>> >>>>>>>>>>>>used, which defaults to zero.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>Ilja
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>Aaron Stone wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>>Here it goes... I'll also post to SourceForge.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>Aaron
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>HEAD is completely updated. I'm having some trouble
>> updating
>> >>>>>>>>>>>>>>dbmail_2_0_branch, due to conflicts when applying patches.
>> I
>> >>>>>>>>>>>>>>guess I'll wait with updating that branch. Or, like
>> somebody
>> >>>>>>>>>>>>>>suggested a while
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>ago,
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>>>>>>do the branching on release of 2.0 final (and abandon the
>> >>>>>>>>>>>>>>current
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>branch
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>>>>>>for now).
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>Good luck finishing your project :)
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>Ilja
>> >>>>>>>>>>>>>>Aaron Stone wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>If you have CVS updated to your latest working tree I'll
>> >>>>>>>>>>>>>>> patch
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>against it
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>>>in a
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>>>>few hours. This moment I have to finish up a project
>> before
>> >>>>>>>>>>>>>>>daybreak.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>Aaron
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>Just tried this for myself. A lot of warnings..
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>I guess the cleaned up statements are in the patches
>> you'll
>> >>>>>>>>>>>>>>>>send me today? ;)
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>I agree we should keep the __attribute__ thing in the
>> >>>>>>>>>>>>>>>>source. It does not cost us anything, and it helps
>> >>>>>>>>>>>>>>>>preventing bugs. Sounds like free lunch to me! :)
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>Ilja
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>Aaron Stone wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>Well that was fun! I also caught three or four more of
>> the
>> >>>>>>>>>>>>>>>>>missing
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>comma
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>>>>>>>>>errors, and a handful of "%s, %s: ...." formats that
>> were
>> >>>>>>>>>>>>>>>>>missing the
>> >>>>>>>>>>>>>>>>>__FILE__, __FUNCTION arguments.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>I cleaned up all of the warnings, though we should
>> >>>>>>>>>>>>>>>>>definitely keep
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>the GNU
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>>>>>>>>attribute in the source to warn against format bugs in
>> the
>> >>>>>>>>>>>>>>>>>future.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>Aaron
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>I found the GNU extension to turn on pritnf style
>> format
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>checking! In
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>>>>>debug.h,
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>make this your declaration of trace():
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>void trace(int level, char *formatstring, ...)
>> >>>>>>>>>>>>>>>>>> __attribute__((format(printf, 2, 3)));
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>Voila, tons of errors next time you make.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>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
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>--
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>--
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>_______________________________________________
>> >>>>>>>>>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
>> >>>>
>> >>>>_______________________________________________
>> >>>>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
>>
>
>
>
> --
>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

Oh, I just read the patch again and now I get it :-P

Maybe a more thorough refactoring of the configuration code is in order? At
the very least, it looks like we're going to be moving a lot of the
configuration back into the database during the 2.1 development phase.

Aaron


""Leif Jackson"" <ljackson@jjcons.com> said:

> The change was more to get the lists created for the configs out of the
> way for my debugging, I like the idea of not keeping stuff around any
> longer than it has to... The change doesn't fix any memory leak that i can
> tell as I said in the first message. I just think it looks cleaner.
> *shrug*
>
> -leif
>
> > I'm really confused about what's being freed... I haven't been seeing any
> > other memory leaks from dbmail-smtp except for MySQL's internal
> > allocations.
> >
> > Aaron
> >
> >
> > ""Leif Jackson"" <ljackson@jjcons.com> said:
> >
> >> All,
> >>
> >> I found one ting this breaks I will send a patch shortly.. Bascialy
> >> bounce.c uses the config as a global. I don't see that this is a great
> >> idea? I will be moving:
> >> field_t dbmail_from_address, sendmail, postmaster;
> >>
> >> to be global instead, so I can still FreeConfig in the main function.
> >>
> >> Thanks,
> >> Leif
> >>
> >>
> >> > Cool,
> >> >
> >> > Ilja, I have attached a patch that adds a FreeConfig function, this
> >> > doesn't solve my memory leaks from list.c addnode, but makes it a lot
> >> > easier to debug as it free's the config list's right after their used
> >> > instead of at the end of the main (). Please commit it to cvs if you
> >> feel
> >> > it warrants it.
> >> >
> >> > Thanks,
> >> > leif
> >> >
> >> >
> >> >> I've put the patch in CVS, because we'll need it anyway. This way,
> >> it's
> >> >> also easier to debug it, because a simple cvs update will get
> >> everybody
> >> >> the new code :)
> >> >>
> >> >> The delivery chain is still buggy: When delivering messages through
> >> >> LMTP, all messages get delivered twice.
> >> >>
> >> >> Ilja
> >> >>
> >> >> Leif Jackson wrote:
> >> >>
> >> >>> Ilja & Aaron,
> >> >>>
> >> >>> I am looking for this patch. I cannot access it from sourceforge?
> >> Or
> >> >>> do
> >> >>> I
> >> >>> have to checkout from cvs differently than the default dbmail root?
> >> I
> >> >>> would be glad to look at this.... Also Aaron, i was working on your
> >> >>> sieve
> >> >>> code but there are some issues between the current libsieve you have
> >> in
> >> >>> cvs and the last one posed on sourceforge, the api and the lib
> >> doesn't
> >> >>> match quite right or at least not to the code you have in the dbmail
> >> >>> cvs
> >> >>> tree, i am really exited about this feature and would like to help.
> >> >>>
> >> >>> Thanks,
> >> >>> Leif
> >> >>>
> >> >>>
> >> >>>
> >> >>>>Hi,
> >> >>>>
> >> >>>>don't know why, but I just cannot find the reason why the delivery
> >> >>>>user_idnr is added to the userids-list in the dsn twice. It does not
> >> >>>>happen when using dbmail-smtp, only when using dbmail-lmtp.
> >> >>>>
> >> >>>>Aaron (or anybody else), can you take a look at this? I'm
> >> completely
> >> >>>>lost at the moment.. :(
> >> >>>>
> >> >>>>Also, there is the problem with the read_header() function. Some
> >> >>>> testing
> >> >>>>has revealed that it always functions the first time an instance of
> >> >>>>dbmail-lmtp gets a message. The second time that the same instance
> >> of
> >> >>>>the daemon gets a message, it reads the output from the MTA (postfix
> >> in
> >> >>>>my case) very slowly. Are we forgetting to cleanup something?
> >> >>>>
> >> >>>>Ilja
> >> >>>>
> >> >>>>
> >> >>>>Ilja Booij wrote:
> >> >>>>
> >> >>>>
> >> >>>>>I haven't found the cause of this bug yet. There is also still a
> >> >>>>> problem
> >> >>>>>with the read_header() function. It's constantly hanging on an
> >> fgets
> >> >>>>>there..
> >> >>>>>
> >> >>>>>Ilja
> >> >>>>>
> >> >>>>>Ilja Booij wrote:
> >> >>>>>
> >> >>>>>
> >> >>>>>>There is no problem when sending messages through dbmail-smtp,
> >> only
> >> >>>>>>when using lmtp. Strange..
> >> >>>>>>
> >> >>>>>>looking further
> >> >>>>>>
> >> >>>>>>Ilja
> >> >>>>>>
> >> >>>>>>Ilja Booij wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>>Now there's another problem with deliveries. I get every mail
> >> twice!
> >> >>>>>>>
> >> >>>>>>>I'm firing up gdb as I type..
> >> >>>>>>>
> >> >>>>>>>Ilja
> >> >>>>>>>
> >> >>>>>>>Aaron Stone wrote:
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>>Posted to SourceForge. A little patch to pipe.c and header.c,
> >> which
> >> >>>>>>>>fixes a
> >> >>>>>>>>buffer boundary issue in the newline/rfc counting, the forgotten
> >> >>>>>>>>delivery
> >> >>>>>>>>useridnr loop and a missing rfcsize argument to
> >> sort_and_deliver.
> >> >>>>>>>>
> >> >>>>>>>>It's also a proper forwards patch now :-P
> >> >>>>>>>>
> >> >>>>>>>>Aaron
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>Excuses, excuses. See SourceForge for an updated version of the
> >> >>>>>>>>>previously
> >> >>>>>>>>>posted patch; I neglected to add the new rfcsize arguments to
> >> the
> >> >>>>>>>>>sort call,
> >> >>>>>>>>>and something else gone wrong read_header(). Valgrinding as we
> >> >>>>>>>>>speak!
> >> >>>>>>>>>
> >> >>>>>>>>>Aaron
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>>Now I remember! I continued fixing a bug or two in the
> >> >>>>>>>>>>2.0rc2-fixes-snap1
> >> >>>>>>>>>>tree after I'd made the patches from it. But to start clean, I
> >> >>>>>>>>>>took a fresh
> >> >>>>>>>>>>2.0rc2, applied the patches, and then started working towards
> >> the
> >> >>>>>>>>>>next set
> >> >>>>>>>>>>of patches... apparently without bringing this bugfix into the
> >> >>>>>>>>>> new
> >> >>>>>>>>>>tree :-\
> >> >>>>>>>>>>
> >> >>>>>>>>>>I read over the rest of the diff to make sure that I didn't
> >> leave
> >> >>>>>>>>>>anything
> >> >>>>>>>>>>else out, and this does seem to be the only thing I missed.
> >> >>>>>>>>>>
> >> >>>>>>>>>>Apply the attached patch, *reversed* (because I really need
> >> sleep
> >> >>>>>>>>>>:-P)
> >> >>>>>>>>>>
> >> >>>>>>>>>>Aaron
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>""Aaron Stone"" <aaron@serendipity.palo-alto.ca.us> said:
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>>Oh, weird. I really did fix that already; I'll see if maybe I
> >> >>>>>>>>>>>fixed it in an
> >> >>>>>>>>>>>older tree by accident. Will post a patch this afternoon.
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>Aaron
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>I've applied the patch (have not updated CVS yet).
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>I ran into the following problem:
> >> >>>>>>>>>>>>When delivering a message, all message go into the mailbox
> >> of
> >> >>>>>>>>>>>>user_idnr 0 (that is: zero).
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>The problem seems to be, that the user_idnrs to deliver the
> >> >>>>>>>>>>>>messages to are kept in delivery->userids (in a list), but
> >> that
> >> >>>>>>>>>>>>this list is never used when attempting delivery. The
> >> >>>>>>>>>>>>delivery->userids field is not used when calling
> >> >>>>>>>>>>>>sort_and_deliver(). In that call, only delivery->useridnr is
> >> >>>>>>>>>>>>used, which defaults to zero.
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>Ilja
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>Aaron Stone wrote:
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>
> >> >>>>>>>>>>>>>Here it goes... I'll also post to SourceForge.
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>Aaron
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>HEAD is completely updated. I'm having some trouble
> >> updating
> >> >>>>>>>>>>>>>>dbmail_2_0_branch, due to conflicts when applying patches.
> >> I
> >> >>>>>>>>>>>>>>guess I'll wait with updating that branch. Or, like
> >> somebody
> >> >>>>>>>>>>>>>>suggested a while
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>ago,
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>>>>>>do the branching on release of 2.0 final (and abandon the
> >> >>>>>>>>>>>>>>current
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>branch
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>>>>>>for now).
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>Good luck finishing your project :)
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>Ilja
> >> >>>>>>>>>>>>>>Aaron Stone wrote:
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>If you have CVS updated to your latest working tree I'll
> >> >>>>>>>>>>>>>>> patch
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>against it
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>>>in a
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>
> >> >>>>>>>>>>>>>>>few hours. This moment I have to finish up a project
> >> before
> >> >>>>>>>>>>>>>>>daybreak.
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>Aaron
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>Ilja Booij <ilja@ic-s.nl> said:
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>Just tried this for myself. A lot of warnings..
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>I guess the cleaned up statements are in the patches
> >> you'll
> >> >>>>>>>>>>>>>>>>send me today? ;)
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>I agree we should keep the __attribute__ thing in the
> >> >>>>>>>>>>>>>>>>source. It does not cost us anything, and it helps
> >> >>>>>>>>>>>>>>>>preventing bugs. Sounds like free lunch to me! :)
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>Ilja
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>Aaron Stone wrote:
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>Well that was fun! I also caught three or four more of
> >> the
> >> >>>>>>>>>>>>>>>>>missing
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>comma
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>>>>>>>>>errors, and a handful of "%s, %s: ...." formats that
> >> were
> >> >>>>>>>>>>>>>>>>>missing the
> >> >>>>>>>>>>>>>>>>>__FILE__, __FUNCTION arguments.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>I cleaned up all of the warnings, though we should
> >> >>>>>>>>>>>>>>>>>definitely keep
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>the GNU
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>attribute in the source to warn against format bugs in
> >> the
> >> >>>>>>>>>>>>>>>>>future.
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>Aaron
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>"Aaron Stone" <aaron@serendipity.palo-alto.ca.us> said:
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>I found the GNU extension to turn on pritnf style
> >> format
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>checking! In
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>>>>>>>debug.h,
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>make this your declaration of trace():
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>void trace(int level, char *formatstring, ...)
> >> >>>>>>>>>>>>>>>>>> __attribute__((format(printf, 2, 3)));
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>Voila, tons of errors next time you make.
> >> >>>>>>>>>>>>>>>>>>
> >> >>>>>>>>>>>>>>>>>>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
> >> >>>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>--
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>--
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>_______________________________________________
> >> >>>>>>>>>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
> >> >>>>
> >> >>>>_______________________________________________
> >> >>>>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
> >>
> >
> >
> >
> > --
> >
> >
> >
> > _______________________________________________
> > 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
>



--

If that (config in the database) is going to happen again, one thing that is
worth considering is a run-time dynamic config system, so you can change the
behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it
this weekend.

-----Original Message-----
From: dbmail-dev-admin@dbmail.org [mailto:dbmail-dev-admin@dbmail.org] On
Behalf Of Aaron Stone
Sent: Wednesday, March 03, 2004 7:06 PM
To: dbmail-dev@dbmail.org
Subject: Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks
.. was format errors in calls to trace()

Oh, I just read the patch again and now I get it :-P

Maybe a more thorough refactoring of the configuration code is in order? At
the very least, it looks like we're going to be moving a lot of the
configuration back into the database during the 2.1 development phase.

Aaron

That might be cool, I think that we need to carfully look at performance
of any config related stuff. The config should be read once, and for
things like dbmail-smtp it should do as little as possible as it is read
each time. I know the lmtpd is the answer to not re-reading configs each
time but not everyone will be able to use it. I would be intersted in what
you were thinking about run-time dynamic config?

Thanks,
Leif


> If that (config in the database) is going to happen again, one thing that
> is
> worth considering is a run-time dynamic config system, so you can change
> the
> behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it
> this weekend.
>
> -----Original Message-----
> From: dbmail-dev-admin@dbmail.org [mailto:dbmail-dev-admin@dbmail.org] On
> Behalf Of Aaron Stone
> Sent: Wednesday, March 03, 2004 7:06 PM
> To: dbmail-dev@dbmail.org
> Subject: Re: [Dbmail-dev] adding FreeConfig while tracking down memory
> leaks
> .. was format errors in calls to trace()
>
> Oh, I just read the patch again and now I get it :-P
>
> Maybe a more thorough refactoring of the configuration code is in order?
> At
> the very least, it looks like we're going to be moving a lot of the
> configuration back into the database during the 2.1 development phase.
>
> Aaron
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

I'm thinking that, for example, some option that determines how messages are
delivered might be re-read by the lmtp server as each message is delivered.
That way, you just change the option in the database and it immediately takes
effect from then on. In contrast, you'd make changed to the config options and
then send a SIGHUP, which would cause the daemon to re-read its configs.

Aaron


""Leif Jackson"" <ljackson@jjcons.com> said:

> That might be cool, I think that we need to carfully look at performance
> of any config related stuff. The config should be read once, and for
> things like dbmail-smtp it should do as little as possible as it is read
> each time. I know the lmtpd is the answer to not re-reading configs each
> time but not everyone will be able to use it. I would be intersted in what
> you were thinking about run-time dynamic config?
>
> Thanks,
> Leif
>
>
> > If that (config in the database) is going to happen again, one thing that
> > is
> > worth considering is a run-time dynamic config system, so you can change
> > the
> > behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it
> > this weekend.
> >
> > -----Original Message-----
> > From: dbmail-dev-admin@dbmail.org [mailto:dbmail-dev-admin@dbmail.org] On
> > Behalf Of Aaron Stone
> > Sent: Wednesday, March 03, 2004 7:06 PM
> > To: dbmail-dev@dbmail.org
> > Subject: Re: [Dbmail-dev] adding FreeConfig while tracking down memory
> > leaks
> > .. was format errors in calls to trace()
> >
> > Oh, I just read the patch again and now I get it :-P
> >
> > Maybe a more thorough refactoring of the configuration code is in order?
> > At
> > the very least, it looks like we're going to be moving a lot of the
> > configuration back into the database during the 2.1 development phase.
> >
> > 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
>



--

Hi,

Leif Jackson wrote:
> Attached is the new patch with the slight change I figured for now the
> easiest was to just move the FreeConfig for the smtpItems to the end of
> freeall:, well maybe we want to think about a struct for these items that
> can be global instead of the listnodes, *shrug* let me know.
I'm kind of wondering if we should add this to 2.0. On the one hand, it
sounds like something we can really use. On the other hand, it is not
just a fix, but more of a refactoring of the code, which I intend to
delay until after the 2.0 release.
>
> Thanks,
> Leif
>
> p.s. I belive after a lopng bout of checks with valgrind ( an amazing
> package for many reasons) that the memory leaks if any are only in the
> main function of pop3, as far as I can tell imapd is clean! :)
OK... so we need to check POP3 for memleaks.
> p.p.s. I have started on server side sorting code, may have something by
> this weekend I can share. has ISCS thought about or started any similar
> code before I get to far into it? thx.
We have not started any server side sorting code (IMAP SORT & THREAD)
yet. So please go ahead. Please mind that this code will not go into
2.0. If it ready soon it will go into 2.1. Sorry for that, but we really
need to stop adding features to 2.0 and just get it to work. We'll move
on after that.

Ilja

>
>
>>All,
>>
>> I found one ting this breaks I will send a patch shortly.. Bascialy
>>bounce.c uses the config as a global. I don't see that this is a great
>>idea? I will be moving:
>>field_t dbmail_from_address, sendmail, postmaster;
>>
>>to be global instead, so I can still FreeConfig in the main function.
>>
>>Thanks,
>>Leif
>>
>>
>>
>>>Cool,
>>>
>>> Ilja, I have attached a patch that adds a FreeConfig function, this
>>>doesn't solve my memory leaks from list.c addnode, but makes it a lot
>>>easier to debug as it free's the config list's right after their used
>>>instead of at the end of the main (). Please commit it to cvs if you
>>>feel
>>>it warrants it.
>>>
>>>Thanks,
>>>leif
>>>
>>>
>>>
>>>>I've put the patch in CVS, because we'll need it anyway. This way, it's
>>>>also easier to debug it, because a simple cvs update will get everybody
>>>>the new code :)
>>>>
>>>>The delivery chain is still buggy: When delivering messages through
>>>>LMTP, all messages get delivered twice.
>>>>
>>>>Ilja
>>>>
>>>>Leif Jackson wrote:
>>>>
>>>>
>>>>>Ilja & Aaron,
>>>>>
>>>>> I am looking for this patch. I cannot access it from sourceforge? Or
>>>>>do
>>>>>I
>>>>>have to checkout from cvs differently than the default dbmail root? I
>>>>>would be glad to look at this.... Also Aaron, i was working on your
>>>>>sieve
>>>>>code but there are some issues between the current libsieve you have
>>>>>in
>>>>>cvs and the last one posed on sourceforge, the api and the lib doesn't
>>>>>match quite right or at least not to the code you have in the dbmail
>>>>>cvs
>>>>>tree, i am really exited about this feature and would like to help.
>>>>>
>>>>>Thanks,
>>>>>Leif
>>>>>
>>>>>