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