Aaron Paul,
I belive I have come up with a fix for this and I have also found a few
extra possible memory leaks, I will submit a patch for your review here
in a bit but I have a question for Paul and the testimap.py with the
current head compiled shared with mysql and no sieve i got one failed
On Tue, February 28, 2006 5:54 pm, Leif Jackson wrote:
Aaron Paul,
I belive I have come up with a fix for this and I have also found a few
extra possible memory leaks, I will submit a patch for your review here in
a bit
what i tried didn't quite workout right so Aaron if you have some
See attached valgrind suppression file. I have added the libmodule leaks
to the suppression file. So it make debugging the other stuff a bit
better. Didn't know if you guys had already done this Should the
suppressions file be included in contrib ?
Aaron ..etc. I have also attached the
On Tue, 2006-02-28 at 22:03 +0100, Paul J Stevens wrote:
I've refactored the whole do {} while... loop into a new function in
server.c
I'll do the stress test later...
All daemons pass with flying colors!
Aaron
On Wed, March 1, 2006 1:03 am, Aaron Stone wrote:
On Tue, 2006-02-28 at 19:02 -0500, Leif Jackson wrote:
On Tue, February 28, 2006 5:54 pm, Leif Jackson wrote:
I belive I have come up with a fix for this and I have also found a
few extra possible memory leaks, I will submit a patch for your
I've just checked in some changes in the server code. SIGHUPs are now
handled correctly. Oleg and Aaron, please test and confirm if you don't
mind. If this works out, 2.1.4 can be released later this week.
Aaron Stone wrote:
On Mon, 2006-02-27 at 12:28 +0300, Oleg Lapshin wrote:
Hello
And
On Mon, 2006-02-27 at 12:28 +0300, Oleg Lapshin wrote:
Hello
And again, troubles with address already in use
Got it! If I hit the parent process with lots of fast SIGHUPs, I can
cause it to die, but leave children that look like parents:
nobody 30203 1 0 09:25
I've just checked in some changes in the server code. SIGHUPs are now
handled correctly. Oleg and Aaron, please test and confirm if you don't
mind. If this works out, 2.1.4 can be released later this week.
No.
The 1st connect from client to dbmail-imapd works fine,
but the 2nd - don't at all
On Tue, 2006-02-28 at 11:54 +0300, Oleg Lapshin wrote:
Two words about kmail and sieve.
I try to change sieve-script from kmail,
but when I try to download script to change it, I get error from kmail
protocol error.
timsieved log output:
The log snippet from DBMail's side of
Found it. db_check_connection called from StartServer was being called
before db_connect which load the module.
Oleg Lapshin wrote:
I've just checked in some changes in the server code. SIGHUPs are now
handled correctly. Oleg and Aaron, please test and confirm if you don't
mind. If this works
Here's another one. I'm getting permission denied errors when the
parent process tries to grab the socket again after SIGHUP. Before
giving the HUP, the parent process is still running with root privs.
Feb 28 04:41:11 [dbmail/imap4d] server.c,StartServer: starting main
service loop
Feb 28
Paul,
Reading from imapd.c, through server.c, and to pool.c, it looks like the
process path is like this:
imapd.c: parent process (root)
imapd.c: child process (nobody)
server.c, pool.c: manage more children (more nobodies)
When you send a HUP to the parent, it does this:
imapd.c: parent
Aaron Stone wrote:
Paul,
Reading from imapd.c, through server.c, and to pool.c, it looks like the
process path is like this:
imapd.c: parent process (root)
imapd.c: child process (nobody)
server.c, pool.c: manage more children (more nobodies)
check. That's the idea.
When you
On Tue, Feb 28, 2006, Paul J Stevens [EMAIL PROTECTED] said:
Aaron Stone wrote:
This fixes it for me:
--- ../dbmail/imapd.c 2006-02-28 04:15:22.556837664 -0800
+++ imapd.c 2006-02-28 10:16:50.398784536 -0800
case 0:
/* child process */
On Tue, February 28, 2006 3:42 pm, Aaron Stone wrote:
On Tue, Feb 28, 2006, Paul J Stevens [EMAIL PROTECTED] said:
Aaron Stone wrote:
This fixes it for me:
--- ../dbmail/imapd.c 2006-02-28 04:15:22.556837664 -0800
+++ imapd.c 2006-02-28 10:16:50.398784536 -0800
case 0: /* child
Aaron Stone wrote:
On Tue, Feb 28, 2006, Paul J Stevens [EMAIL PROTECTED] said:
Aaron Stone wrote:
This fixes it for me:
--- ../dbmail/imapd.c 2006-02-28 04:15:22.556837664 -0800
+++ imapd.c 2006-02-28 10:16:50.398784536 -0800
case 0:
/* child process */
On Tue, Feb 28, 2006, Leif Jackson [EMAIL PROTECTED] said:
Guys before 2.1.4 rel, what about that memory leak issue in imapd?, did
you find a workaround? This is the malloc for () keys in the command
parser I am talking about.
Oh. Hrmm... I'll try to take a look at it tonight. I think the
On Tue, February 28, 2006 4:59 pm, Aaron Stone wrote:
On Tue, Feb 28, 2006, Leif Jackson [EMAIL PROTECTED] said:
Guys before 2.1.4 rel, what about that memory leak issue in imapd?, did
you find a workaround? This is the malloc for () keys in the command
parser I am talking about.
Oh.
On Mon, 2006-02-27 at 12:28 +0300, Oleg Lapshin wrote:
Hello
And again, troubles with address already in use
Got it! If I hit the parent process with lots of fast SIGHUPs, I can
cause it to die, but leave children that look like parents:
nobody 30203 1 0 09:25
19 matches
Mail list logo
