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