The following issue has been RESOLVED.
======================================================================
http://www.dbmail.org/mantis_new/view.php?id=258
======================================================================
Reported By: mavetju
Assigned To: paul
======================================================================
Project: DBMail
Issue ID: 258
Category: General
Reproducibility: always
Severity: block
Priority: normal
Status: resolved
Resolution: fixed
Fixed in Version: 2.0 branch
======================================================================
Date Submitted: 22-Aug-05 02:56 CEST
Last Modified: 22-Aug-05 16:16 CEST
======================================================================
Summary: pool.c doesn't restart all unregistered childs
Description:
When reaching the maxconnections, children die but do not get replaced.
This is different behaviour compared with 2.0.4.
It goes for both the POP3 and IMAP server.
======================================================================
----------------------------------------------------------------------
paul - 22-Aug-05 10:16
----------------------------------------------------------------------
This was fixed by slightly changing the behaviour in the scale-up logic of
manage_spare_children.
----------------------------------------------------------------------
mavetju - 22-Aug-05 10:43
----------------------------------------------------------------------
Can you tell me which revisions of what files I should compare to get a
patch for this problem? Please note that I'm already running 2.0.6.
----------------------------------------------------------------------
paul - 22-Aug-05 11:04
----------------------------------------------------------------------
svn diff -r 1860:1861 pool.c server.c
----------------------------------------------------------------------
mavetju - 22-Aug-05 12:28
----------------------------------------------------------------------
It works better (at least on the short term), but when I came back it
seemed that my "echo quit | nc popserver pop3" has still managed to kill
the pop3 server.
----------------------------------------------------------------------
paul - 22-Aug-05 12:58
----------------------------------------------------------------------
I'm running the same test here right now. Looks clean to me on
trace_level=5
and maxconnections=10
----------------------------------------------------------------------
mavetju - 22-Aug-05 13:04
----------------------------------------------------------------------
dbmail-pop3d in malloc(): error: recursive call
And in the syslog:
Aug 22 20:56:52 mag kernel: pid 14466 (dbmail-pop3d), uid 65534: exited on
signal 6
If you have a spare moment, you can find me on #dbmail on freenode.net.
----------------------------------------------------------------------
mavetju - 22-Aug-05 13:15
----------------------------------------------------------------------
the recursive malloc is because of calling the trace() in the signal
handler of alarm(10) in your patch.
See the man page of malloc(3):
recursive call A process has attempted to call an allocation
function
recursively. This is not permitted. In particular, signal handlers
should not attempt to allocate memory.
sprintf() and friends call malloc().
http://www.dbmail.org/mantis_new/view.php?id=11 0x28151352 in fprintf () from
/lib/libc.so.5
http://www.dbmail.org/mantis_new/view.php?id=12 0x2814e231 in vsyslog () from
/lib/libc.so.5
http://www.dbmail.org/mantis_new/view.php?id=13 0x2807e618 in trace
(level=TRACE_ERROR,
formatstring=0xe218 <Address 0xe218 out of bounds>) at debug.c:91
http://www.dbmail.org/mantis_new/view.php?id=14 0x2808a765 in getKey (pid=57880)
at pool.c:262
http://www.dbmail.org/mantis_new/view.php?id=15 0x2808a79e in scoreboard_release
(pid=4) at pool.c:175
http://www.dbmail.org/mantis_new/view.php?id=16 0x2808980c in ParentSigHandler
(sig=672640348, info=0x2817d5ec,
data=0x804f260) at server.c:183
http://www.dbmail.org/mantis_new/view.php?id=17 0x00000014 in ?? ()
http://www.dbmail.org/mantis_new/view.php?id=18 0x2817ad5c in _malloc_message ()
from /lib/libc.so.5
I admit that the stress test being done now is not realistic in 99% of the
live situations (that's what stress tests are for), but it shows problems
in the implementation.
----------------------------------------------------------------------
paul - 22-Aug-05 14:14
----------------------------------------------------------------------
I think I nailed this one by making the message buffer in trace a static
one.
Could you please try revision 1862
svn diff -r 1861:1862 debug.c
----------------------------------------------------------------------
paul - 22-Aug-05 16:16
----------------------------------------------------------------------
I'm setting this bug to resolved. The issue with malloc/freebsd in
sighandlers is unrelated to this report.
Issue History
Date Modified Username Field Change
======================================================================
22-Aug-05 02:56 mavetju New Issue
22-Aug-05 02:56 mavetju File Added: dbmail.txt
22-Aug-05 10:16 paul Status new => resolved
22-Aug-05 10:16 paul Resolution open => fixed
22-Aug-05 10:16 paul Assigned To => paul
22-Aug-05 10:16 paul Note Added: 0000850
22-Aug-05 10:43 mavetju Status resolved => feedback
22-Aug-05 10:43 mavetju Resolution fixed => reopened
22-Aug-05 10:43 mavetju Note Added: 0000858
22-Aug-05 11:04 paul Note Added: 0000859
22-Aug-05 12:28 mavetju Note Added: 0000860
22-Aug-05 12:58 paul Note Added: 0000861
22-Aug-05 13:04 mavetju Note Added: 0000862
22-Aug-05 13:15 mavetju Note Added: 0000863
22-Aug-05 14:14 paul Note Added: 0000864
22-Aug-05 16:16 paul Note Added: 0000867
22-Aug-05 16:16 paul Status feedback => resolved
22-Aug-05 16:16 paul Resolution reopened => fixed
22-Aug-05 16:16 paul Fixed in Version => 2.0 branch
======================================================================
