Re: Tons of format errors in calls to trace()

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@...> 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@...> 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@...> 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@...> 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@...> 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@...> 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@...> 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@...
>>>>>>>>>>>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>_______________________________________________
>>>>>>>>>>>>Dbmail-dev mailing list
>>>>>>>>>>>>Dbmail-dev@...
>>>>>>>>>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>_______________________________________________
>>>>>>>>>>Dbmail-dev mailing list
>>>>>>>>>>Dbmail-dev@...
>>>>>>>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>--
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>_______________________________________________
>>>>>>>>>Dbmail-dev mailing list
>>>>>>>>>Dbmail-dev@...
>>>>>>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>--
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>--
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>_______________________________________________
>>>>>>>Dbmail-dev mailing list
>>>>>>>Dbmail-dev@...
>>>>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>_______________________________________________
>>>>>Dbmail-dev mailing list
>>>>>Dbmail-dev@...
>>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>>
>>>>
>>>>_______________________________________________
>>>>Dbmail-dev mailing list
>>>>Dbmail-dev@...
>>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>>
>>>_______________________________________________
>>>Dbmail-dev mailing list
>>>Dbmail-dev@...
>>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@...
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
> 
> 
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@...
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev