Nevermind on the not exiting that was a issue I was causing with the debuging options. thx.
-leif > Ilja, > > Correction I wiped my cvs out and re-checked it out and the changes are > there. I was expecting the update command to merge the changes is this > not the case with the dbmail cvs tree? > > On the list.c stuff I see this with the dmalloc lib we talked about a > while back, do you knotice a state where the imapd and pop3d daemons will > not exit when given a sig term? I am having an issue with them while > debugging and I don't in the cvs from 1/12/04. Any ideas? If you want > this patch for dmalloc let me know I will be glad to send it on so you > can check with it yourself. > > Thanks, > leif > > p.s. Aaron I still want to help on the libsieve and sieve code, and to > anyone else if you have the framework for server side sorting and > threading I would like to help with that otherwise I may have to write it > myself :) Thanks. > > >> 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 >
