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
>
