Hello,
When opening some MIME messages (generally with attachments or something like this) I get a "zero sized reply" from the webserver, caused by a memory allocation error of php4 module. The error is reported in the /logs/errors file of RC; here's the transcript:
[10-Apr-2006 14:25:34] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1419154 bytes) in /data/.home/www/horus.ch/www/roundcubemail/program/lib/Mail/mimeDecode.php on line 388
It happens in the mimeDecode.php file at this line:
if (preg_match("/^(.*?)\r?\n\r?\n(.*)/s", $input, $match)) { return array($match[1], $match[2]); }
So, it looks like the perl-like regular expression on a too long message needs too much memory and it somehow dies.
I'm not a php-freak so I've no real idea how to solve this.
Should I have posted that in the bugs tracking system ?
Thanks for your help, kind regards
You need to increase your php memory limit in the php.ini file:
I use this: memory_limit = 64M
I have only seen RC use 20 megs.
On Mon, 10 Apr 2006, Alexis Domjan wrote:
Hello,
When opening some MIME messages (generally with attachments or something like this) I get a "zero sized reply" from the webserver, caused by a memory allocation error of php4 module. The error is reported in the /logs/errors file of RC; here's the transcript:
[10-Apr-2006 14:25:34] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1419154 bytes) in /data/.home/www/horus.ch/www/roundcubemail/program/lib/Mail/mimeDecode.php on line 388
It happens in the mimeDecode.php file at this line:
if (preg_match("/^(.*?)\r?\n\r?\n(.*)/s", $input, $match)) { return array($match[1], $match[2]); }
So, it looks like the perl-like regular expression on a too long message needs too much memory and it somehow dies.
I'm not a php-freak so I've no real idea how to solve this.
Should I have posted that in the bugs tracking system ?
Thanks for your help, kind regards -- Alexis Domjan adomjan@horus.ch
Jon Daley http://jon.limedaley.com/
If you want to make enemies, try to change something. -- Woodrow Wilson
On 10 Apr 2006, at 13:51, Jon Daley wrote:
You need to increase your php memory limit in the php.ini file:
I use this: memory_limit = 64M
I have only seen RC use 20 megs.
Quick heads-up to say that this could be a fair problem for some
shared hosts. Here we allow up to 24M per process because a lot of
our customers run Drupal or Civicspace which needs a good bit of
memory, but it's more usual for the default to be left in there at 8M.
Does anyone have ideas for how to work this out? Perhaps splitting up
$input a little before the regular expression?
Yours, Craig -- Craig Webster | t: +44 (0)131 516 8595 | e: craig@xeriom.net Xeriom.NET | f: +44 (0)131 661 0689 | w: http://xeriom.net
Craig Webster wrote:
On 10 Apr 2006, at 13:51, Jon Daley wrote:
You need to increase your php memory limit in the php.ini file:
I use this: memory_limit = 64M
I have only seen RC use 20 megs.
Quick heads-up to say that this could be a fair problem for some shared hosts. Here we allow up to 24M per process because a lot of our customers run Drupal or Civicspace which needs a good bit of memory, but it's more usual for the default to be left in there at 8M.
Does anyone have ideas for how to work this out? Perhaps splitting up $input a little before the regular expression?
The main problem is, that this PEAR class is not very efficient and requires the whole message source for input. Memory usage gets high when opening multipart messages. If you get a mail with a 20M attachment you would run into memory problems even if you split $input.
The only solution is to fetch only the message structure from IMAP and analyze the parts. But this is a major change and will not be solved within a couple of days. The only solution for now is to increase the memory_limit in php.ini
Yours, Craig
Regards, Thomas
Hi!
Craig Webster wrote:
Quick heads-up to say that this could be a fair problem for some shared hosts. Here we allow up to 24M per process because a lot of our customers run Drupal or Civicspace which needs a good bit of memory, but it's more usual for the default to be left in there at 8M.
Does anyone have ideas for how to work this out? Perhaps splitting up $input a little before the regular expression?
<?php ini_set('memory_limit', '32M'); ?>
Dmitry.
Hi All, I had posted this delete problem quite some time back. Anyhow, I'm still facing it. When I delete, the mail disappears from INBOX, but upon refreshing the browser, it reappears. The Roundcube Version is: 0.1-20051021 I was told to check for the Trash dir on the server. It exists under the users home dir. The mail server is Postfix, and mailbox is in Maildir format.
Thanks, Nitin
You should upgrade your RC installation because 0.1-20051021 is definitely out of date. Newer versions should show a warning in case that moving to another folder failed.
Regards, Thomas
P.S. Please do not reply to a message when opening a new thread.
N P List wrote:
Hi All, I had posted this delete problem quite some time back. Anyhow, I'm still facing it. When I delete, the mail disappears from INBOX, but upon refreshing the browser, it reappears. The Roundcube Version is: 0.1-20051021 I was told to check for the Trash dir on the server. It exists under the users home dir. The mail server is Postfix, and mailbox is in Maildir format.
Thanks, Nitin
Thomas, Thanks for the reply. I did the upgrade. I ran the my sql script: roundcubemail-0.1beta/SQL/mysql.update.sql And got these errors: ERROR 1060 (42S21): Duplicate column name 'ip' ERROR 1060 (42S21): Duplicate column name 'alias' ERROR 1060 (42S21): Duplicate column name 'created'
I checked the script, it was trying to re-creating those tables. Is this expected during upgrading? Anyone else? Anyhow, now when I try to delete the message I get this:
Error sending request /?_auth=cfad38c7c60e05934c9cc67bae4cd9af991c7012&_task=mail&_action=show&_uid=42&_mbox=INBOX
And yes the message still re-appears on refresh. I noticed something else, the UPGRADING file tells to add these in the main.inc.php file:
What does this "$rcmail_config['skip_deleted'] = FALSE;" do?
Thanks again, Nitin
Thomas Bruederli wrote:
You should upgrade your RC installation because 0.1-20051021 is definitely out of date. Newer versions should show a warning in case that moving to another folder failed.
Regards, Thomas
P.S. Please do not reply to a message when opening a new thread.
N P List wrote:
Hi All, I had posted this delete problem quite some time back. Anyhow, I'm still facing it. When I delete, the mail disappears from INBOX, but upon refreshing the browser, it reappears. The Roundcube Version is: 0.1-20051021 I was told to check for the Trash dir on the server. It exists under the users home dir. The mail server is Postfix, and mailbox is in Maildir format.
Thanks, Nitin
Hi All, Anyone? Please. I installed the latest and greatest build of RC (Version 0.1-20060220). Well, I'm getting this when I delete a message: Error sending request:
<long url of the message to be deleted>
Suggestions?
Thanks, Nitin
Thomas Bruederli wrote:
You should upgrade your RC installation because 0.1-20051021 is definitely out of date. Newer versions should show a warning in case that moving to another folder failed.
Regards, Thomas
P.S. Please do not reply to a message when opening a new thread.
N P List wrote:
Hi All, I had posted this delete problem quite some time back. Anyhow, I'm still facing it. When I delete, the mail disappears from INBOX, but upon refreshing the browser, it reappears. The Roundcube Version is: 0.1-20051021 I was told to check for the Trash dir on the server. It exists under the users home dir. The mail server is Postfix, and mailbox is in Maildir format.
Thanks, Nitin