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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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"" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 >> >
