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