Hi,
Yes, sorry. My client indicated that the message never got sent so I
stopped it and resent only to find all this messages later on on the list.
Thanks,
Andy
Aaron Stone wrote:
I believe that you removed the exit() from this loop, too...
while(1)
{
send_to_dbmail_list( &msg_reply_to_roel );
/*
We should stop here, but exit() doesn't work...
Guess we'll just comment this and see what happens ;-)
exit();
*/
}
Aaron
On Fri, 13 Dec 2002, Joby Walker wrote:
Andreas,
Please kill whatever is resending your email over and over and over...
Received: from [192.168.1.160] (localhost.localdomain [127.0.0.1])
by serv0r.modul.us (Postfix) with ESMTP id 4E66B741B0
for <dbmail@dbmail.org>; Fri, 13 Dec 2002 08:36:47 -0800 (PST)
Received: from [192.168.1.160] (localhost.localdomain [127.0.0.1])
by serv0r.modul.us (Postfix) with ESMTP id A0321741B0
for <dbmail@dbmail.org>; Fri, 13 Dec 2002 12:59:33 -0800 (PST)
jbw
Andreas Richter wrote:
Hi,
I agree that this will fix the CPU load problem, but it doesn't really fix
the original cause which is the segment violation. I would rather fix that.
Thanks,
Andy
On 12/13/02 8:49, "Andreas Richter" <[EMAIL PROTECTED]> wrote:
My bad, I was looking at the wrong line. I will recompile.
Thanks,
Andy
On 12/13/02 6:18, "Roel Rozendaal - IC&S" <[EMAIL PROTECTED]> wrote:
I'm referring to the exit() on line 122 in serverchild.c - i've changed
the call to _exit(); the adding of this function resolved our problem
of the imap daemon taking up all cpu time.
Andreas Richter heeft op donderdag, 12 dec 2002 om 16:19
(Europe/Amsterdam) het volgende geschreven:
Hi Roel,
Sorry, but the CVS file does not have the exit anymore. I though you
got rid of it. Also maybe we should just remove the signal handler
before trying to shut down.
Thanks,
Andy
Roel Rozendaal - IC&S wrote:
where are those function calls in the ChildSigHandler() originating
from? The only function the ChildSigHandler() is calling is exit();
but as i recall exit() isn't reentrant for every unix implementation
- could you check the effect of replacing the exit() call by a call
to _exit()? _exit() is POSIX reentrant.
Andreas Richter heeft op donderdag, 12 dec 2002 om 12:31
(Europe/Amsterdam) het volgende geschreven:
Hi,
Here is where the process is stuck:
#0 0x40101591 in chunk_free (ar_ptr=0x401b5300, p=0x8090e18) at
malloc.c:3252
#1 0x401013f4 in __libc_free (mem=0x8090e20) at malloc.c:3154
#2 0x400f1775 in _IO_new_fclose (fp=0x8090e20) at iofclose.c:85
#3 0x08051f7e in ChildSigHandler ()
#4 <signal handler called>
#5 chunk_alloc (ar_ptr=0x401b5300, nb=368) at malloc.c:3001
#6 0x40100828 in __libc_malloc (bytes=360) at malloc.c:2811
#7 0x0804f94b in db_getmailbox ()
#8 0x0804a9cb in IMAPClientHandler ()
#9 0x08052355 in PerformChildTask ()
#10 0x080520df in CreateChild ()
#11 0x080525c4 in StartServer ()
#12 0x08049cfe in main ()
#13 0x4009c657 in __libc_start_main (main=0x8049b30 <main>, argc=1,
ubp_av=0xbffffaf4, init=0x8049418 <_init>, fini=0x80638b0
<_fini>,
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffffaec)
at ../sysdeps/generic/libc-start.c:129
I may be wrong, but freeing whatever this is if probably causing
another
SEGV and restarting the sig handler?! Because it seems that the
malloc fails
due to a memory overwrite?! And it is the same ar_ptr.
Thanks,
Andy
On 12/12/02 5:44, "Roel Rozendaal - IC&S" <[EMAIL PROTECTED]> wrote:
That's curious - we've had exactly this problem with the 1.0 imapd -
after a nasty signal (sigseg/sigbus) the process being signaled just
didn't exit but got stuck somewhere closing the database connection.
That's why I added the exit() to the serverchild.c signalhandler
code.
Since then the problem has no longer occurred. Could you check the
maillog to see if the process taking up all cpu time has had a
signal?
If the last output from that particular process was in fact
something
like 'got signal [..]' there's still something wrong in the signal
handler.
Are you able to reproduce this cpu-time consuming behaviour? If so,
you
could attach to a process using gdb a set a break in the signal
handler
and then continue the program - in fact thinking it over you could
set
up gdb sessions for all your processes in this way.
regards roel
Andreas Richter heeft op woensdag, 11 dec 2002 om 23:48
(Europe/Amsterdam) het volgende geschreven:
The first problem still seems to exist. In fact I think it's worse.
Now I
got 98% of usage for just one process. It's one of the child
processes
that
uses all of the CPU. Doing an strace on it shows no system calls
so the
process seems to be in a tight loop or just doing some internal
calls.
When
I attached with dbg it was stuck in malloc.c, but I didn't get the
stack
trace due to hitting the wrong key :-( sorry! I typed n first
before
doing
the stack trace. I'll send you the info next time.
Thanks,
Andy
On 12/10/02 5:24, "Roel Rozendaal - IC&S" <[EMAIL PROTECTED]> wrote:
Hi andreas,
Your first problem has been fixed - cvs has been updated, i'll
update
the 1.0 release today. The 2nd and 3rd problem you describe are
currently being looked into but all the information you (or anyone
else
on this list) can send is very welcome. For instance, could you be
more
specific on which commands are failing? Thanks!
regards roel
Andreas Richter heeft op maandag, 9 dec 2002 om 12:49
(Europe/Amsterdam) het volgende geschreven:
Hi,
I am having problems with the 1.0 version.
1. IMAPD takes up all of the CPU after a while of being used.
2. POP3D crashes quite often and I had to revert to the rc4
version.
3. IMAPD sometimes doesn't let my client retrieve messages I get
weird
errors in the client saying that commands are invalid or the
like,
but
the
next retrieve works fine.
I don't have any problems debugging this stuff, but I was unable
to
run the
processes under gdb and would like some info on how to do that.
Thanks,
Andy
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
