Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
Hi, Leif Jackson wrote: Attached is the new patch with the slight change I figured for now the easiest was to just move the FreeConfig for the smtpItems to the end of freeall:, well maybe we want to think about a struct for these items that can be global instead of the listnodes, *shrug* let me know. I'm kind of wondering if we should add this to 2.0. On the one hand, it sounds like something we can really use. On the other hand, it is not just a fix, but more of a refactoring of the code, which I intend to delay until after the 2.0 release. Thanks, Leif p.s. I belive after a lopng bout of checks with valgrind ( an amazing package for many reasons) that the memory leaks if any are only in the main function of pop3, as far as I can tell imapd is clean! :) OK... so we need to check POP3 for memleaks. p.p.s. I have started on server side sorting code, may have something by this weekend I can share. has ISCS thought about or started any similar code before I get to far into it? thx. We have not started any server side sorting code (IMAP SORT & THREAD) yet. So please go ahead. Please mind that this code will not go into 2.0. If it ready soon it will go into 2.1. Sorry for that, but we really need to stop adding features to 2.0 and just get it to work. We'll move on after that. Ilja 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
RE: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
I'm thinking that, for example, some option that determines how messages are delivered might be re-read by the lmtp server as each message is delivered. That way, you just change the option in the database and it immediately takes effect from then on. In contrast, you'd make changed to the config options and then send a SIGHUP, which would cause the daemon to re-read its configs. Aaron ""Leif Jackson"" <[EMAIL PROTECTED]> said: > That might be cool, I think that we need to carfully look at performance > of any config related stuff. The config should be read once, and for > things like dbmail-smtp it should do as little as possible as it is read > each time. I know the lmtpd is the answer to not re-reading configs each > time but not everyone will be able to use it. I would be intersted in what > you were thinking about run-time dynamic config? > > Thanks, > Leif > > > > If that (config in the database) is going to happen again, one thing that > > is > > worth considering is a run-time dynamic config system, so you can change > > the > > behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it > > this weekend. > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Aaron Stone > > Sent: Wednesday, March 03, 2004 7:06 PM > > To: dbmail-dev@dbmail.org > > Subject: Re: [Dbmail-dev] adding FreeConfig while tracking down memory > > leaks > > .. was format errors in calls to trace() > > > > Oh, I just read the patch again and now I get it :-P > > > > Maybe a more thorough refactoring of the configuration code is in order? > > At > > the very least, it looks like we're going to be moving a lot of the > > configuration back into the database during the 2.1 development phase. > > > > 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 > --
RE: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
That might be cool, I think that we need to carfully look at performance of any config related stuff. The config should be read once, and for things like dbmail-smtp it should do as little as possible as it is read each time. I know the lmtpd is the answer to not re-reading configs each time but not everyone will be able to use it. I would be intersted in what you were thinking about run-time dynamic config? Thanks, Leif > If that (config in the database) is going to happen again, one thing that > is > worth considering is a run-time dynamic config system, so you can change > the > behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it > this weekend. > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Aaron Stone > Sent: Wednesday, March 03, 2004 7:06 PM > To: dbmail-dev@dbmail.org > Subject: Re: [Dbmail-dev] adding FreeConfig while tracking down memory > leaks > .. was format errors in calls to trace() > > Oh, I just read the patch again and now I get it :-P > > Maybe a more thorough refactoring of the configuration code is in order? > At > the very least, it looks like we're going to be moving a lot of the > configuration back into the database during the 2.1 development phase. > > Aaron > > ___ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >
RE: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
If that (config in the database) is going to happen again, one thing that is worth considering is a run-time dynamic config system, so you can change the behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it this weekend. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Stone Sent: Wednesday, March 03, 2004 7:06 PM To: dbmail-dev@dbmail.org Subject: Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace() Oh, I just read the patch again and now I get it :-P Maybe a more thorough refactoring of the configuration code is in order? At the very least, it looks like we're going to be moving a lot of the configuration back into the database during the 2.1 development phase. Aaron
Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
Oh, I just read the patch again and now I get it :-P Maybe a more thorough refactoring of the configuration code is in order? At the very least, it looks like we're going to be moving a lot of the configuration back into the database during the 2.1 development phase. Aaron ""Leif Jackson"" <[EMAIL PROTECTED]> said: > 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 upda
Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
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
Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
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 >
Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
Attached is the new patch with the slight change I figured for now the easiest was to just move the FreeConfig for the smtpItems to the end of freeall:, well maybe we want to think about a struct for these items that can be global instead of the listnodes, *shrug* let me know. Thanks, Leif p.s. I belive after a lopng bout of checks with valgrind ( an amazing package for many reasons) that the memory leaks if any are only in the main function of pop3, as far as I can tell imapd is clean! :) p.p.s. I have started on server side sorting code, may have something by this weekend I can share. has ISCS thought about or started any similar code before I get to far into it? thx. > 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 dbmail-2.0cvs030304-list.c.diff Description: Binary data
Re: [Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
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 t
[Dbmail-dev] adding FreeConfig while tracking down memory leaks .. was format errors in calls to trace()
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 >>
