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