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 > >
