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
