A BUGNOTE has been added to this bug.
======================================================================
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000258
======================================================================
Reported By: mavetju
Assigned To: paul
======================================================================
Project: DBMail
Bug ID: 258
Category: General
Reproducibility: always
Severity: block
Priority: normal
Status: feedback
======================================================================
Date Submitted: 22-Aug-05 02:56 CEST
Last Modified: 22-Aug-05 13:15 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 CEST
----------------------------------------------------------------------
This was fixed by slightly changing the behaviour in the scale-up logic of
manage_spare_children.
----------------------------------------------------------------------
mavetju - 22-Aug-05 10:43 CEST
----------------------------------------------------------------------
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 CEST
----------------------------------------------------------------------
svn diff -r 1860:1861 pool.c server.c
----------------------------------------------------------------------
mavetju - 22-Aug-05 12:28 CEST
----------------------------------------------------------------------
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 CEST
----------------------------------------------------------------------
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 CEST
----------------------------------------------------------------------
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 CEST
----------------------------------------------------------------------
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/bug_view_advanced_page.php?bug_id=0000011
0x28151352 in fprintf () from /lib/libc.so.5
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000012
0x2814e231 in vsyslog () from /lib/libc.so.5
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000013
0x2807e618 in trace (level=TRACE_ERROR,
formatstring=0xe218 <Address 0xe218 out of bounds>) at debug.c:91
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000014
0x2808a765 in getKey (pid=57880) at pool.c:262
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000015
0x2808a79e in scoreboard_release (pid=4) at pool.c:175
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000016
0x2808980c in ParentSigHandler (sig=672640348, info=0x2817d5ec,
data=0x804f260) at server.c:183
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000017
0x00000014 in ?? ()
http://www.dbmail.org/mantis/bug_view_advanced_page.php?bug_id=0000018
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.
Bug History
Date Modified Username Field Change
======================================================================
22-Aug-05 02:56mavetju New Bug
22-Aug-05 02:56mavetju File Added: dbmail.txt
22-Aug-05 10:16paul Bugnote Added: 0000850
22-Aug-05 10:16paul Assigned To => paul
22-Aug-05 10:16paul Resolution open => fixed
22-Aug-05 10:16paul Status new => resolved
22-Aug-05 10:43mavetju Bugnote Added: 0000858
22-Aug-05 10:43mavetju Resolution fixed => reopened
22-Aug-05 10:43mavetju Status resolved => feedback
22-Aug-05 11:04paul Bugnote Added: 0000859
22-Aug-05 12:28mavetju Bugnote Added: 0000860
22-Aug-05 12:58paul Bugnote Added: 0000861
22-Aug-05 13:04mavetju Bugnote Added: 0000862
22-Aug-05 13:15mavetju Bugnote Added: 0000863
======================================================================
