Bug 184496
Summary: | Random crashes - trying to reply to a message prints most of a blank screen | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Graham Leggett <minfrin> |
Component: | squirrelmail | Assignee: | Michal Hlavinka <mhlavink> |
Status: | CLOSED CANTFIX | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 4.0 | CC: | tokul, trondeg |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-12-09 14:33:41 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Graham Leggett
2006-03-09 10:56:06 UTC
Squirrelmail version is 1.4.3a-12.EL4. I suspect that /etc/php.ini default settings are not great for squirrelmail. Have you tried raising the "memory_limit" option? I personally use "32M". I found reports of "out of memory" inside the server's generic eror_log, and I raised the memory, and the crashes have reduced but not disappeared. Now the following is logged in the virtual host's error_log file: [Fri Mar 17 15:35:22 2006] [error] [client yy] PHP Notice: Object of class ContentType could not be converted to int in /usr/share/squirrelmail/clas s/mime/Rfc822Header.class.php on line 61, referer: https://yy/webmail/ src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX.Funny+Stuff [Fri Mar 17 15:35:22 2006] [error] [client yy] PHP Notice: Trying to get property of non-object in /usr/share/squirrelmail/class/mime/Message.class. php on line 676, referer: https://yy/webmail/src/right_main.php?PG_SHO WALL=0&sort=0&startMessage=1&mailbox=INBOX.Funny+Stuff [Fri Mar 17 15:35:22 2006] [error] [client yy] PHP Notice: Trying to get property of non-object in /usr/share/squirrelmail/class/mime/Message.class. php on line 676, referer: https://yy/webmail/src/right_main.php?PG_SHO WALL=0&sort=0&startMessage=1&mailbox=INBOX.Funny+Stuff The OOM crashes happen a lot on a fresh RHEL4 U3. I still have not seen any signs of problems like this. Out of curiosity, does "setenforce 0" temporarily cause this to no longer fail? Since the httpd runs unconfined (to get password change and vacation to work properly from squirrelmail), this should not be an issue. There were also no SELinux log entried. I did specify that it was a OOM scenario, though - the default limit of 8 M does not seem to be a usable default. The logs were filled with messages like these before the limit was upped: PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 83 bytes) in /usr/share/squirrelmail/src/compose.php on line 841, referer: I suspect that you are using PHP 5.1.4 or newer version with old SquirrelMail version. Your notices can be reproduced only in PHP 5.1.4+. SquirrelMail fixed PHP 5.1.4+ issues in 1.4.6 package. Some 1.4.6 updates fix fatal PHP errors. These errors can be triggered by message priority headers and break message listing. Make sure that you can reproduce your issue in latest SquirrelMail packages and make sure that you have server side sorting turned on in SquirrelMail configuration. Default PHP based sorting hits memory limits on folders with 2-3 thousand and more messages. You can turn on server side sorting in SquirrelMail configuration utility 4. General Options menu section. It should not cause any issues, if you use dovecot or courier-imap compiled with --enable-unicode option. Cyrus IMAP will have server side sorting issues only in Korean translation. Can you still reproduce this issue with updated squirrelmail (>= 1.4.6)? closing this bug because of one and half year long needinfo status |