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 > --
