A NOTE has been added to this issue. ====================================================================== http://www.dbmail.org/mantis/view.php?id=208 ====================================================================== Reported By: gonecrazy25 Assigned To: ====================================================================== Project: DBMail Issue ID: 208 Category: POP3 daemon Reproducibility: always Severity: major Priority: normal Status: new ====================================================================== Date Submitted: 26-May-05 19:39 CEST Last Modified: 31-Jan-06 20:25 CET ====================================================================== Summary: glibc error in dbmail_pop3d Description: After you startup the dbmail_pop3d deamon when a child exits and a new one starts you get this error: *** glibc detected *** corrupted double-linked list: 0x0805bb70 ***
This is what Red Hat has to say about it: The version of glibc provided with Fedora Core 3 performs additional internal sanity checks to prevent and detect data corruption as early as possible. By default, should corruption be detected, a message similar to the following will be displayed on standard error (or logged via syslog if stderr is not open): *** glibc detected *** double free or corruption: 0x0937d008 *** By default, the program that generated this error will also be killed; however, this (and whether or not an error message is generated) can be controlled via the MALLOC_CHECK_ environment variable. The following settings are supported: 0 — Do not generate an error message, and do not kill the program 1 — Generate an error message, but do not kill the program 2 — Do not generate an error message, but kill the program 3 — Generate an error message and kill the program Note If MALLOC_CHECK_ is explicitly set a value other than 0, this causes glibc to perform more tests that are more extensive than the default, and may impact performance. Should you have a program from a third party ISV that triggers these corruption checks and displays a message, you should file a defect report with the application's vendor, since this indicates a serious bug. ------------------------------------------------------- So they say this is a serious bug It happens whenever a new child process starts after the initial load. ====================================================================== ---------------------------------------------------------------------- sr - 29-May-05 15:00 ---------------------------------------------------------------------- I have seen this using dbmail IMAP as well ---------------------------------------------------------------------- blistwon - 31-Jan-06 20:25 ---------------------------------------------------------------------- This issue seems to be pertinent to any dbmail daemon (pop3d, imapd). There are a variety of threads on the issue on the web, most notably ... http://www.gossamer-threads.com/lists/dbmail/dev/12971 ... and a search for the issue ... http://tinyurl.com/bo5jw This also seems to contribute to the bugs related to imapd running slowly over the course of 24-72 hours. Personally, I have to kill and restart the imap daemon about once every 24 hours. If I tail the maillog, I can see that incoming connections are recognized, authenticated, and then they begin to slooowwwwly try to poll the db for messages. My setup is - DBMail 2.0.8 - Fedora Core 3 - Postfix 2.2.8 Any help on getting around the issue, or a patch to fix it would be appreciated. Issue History Date Modified Username Field Change ====================================================================== 26-May-05 19:39 gonecrazy25 New Issue 29-May-05 15:00 sr Note Added: 0000715 31-Jan-06 20:25 blistwon Note Added: 0000982 ======================================================================
