SquirrelMail  
Donations
News
About
Support
Screen shots
Download
Plugins
Documentation
Sponsors
Bounties













Security Notice
Phishing campain
UPDATE YOUR
EMAIL SECURITY
"IUEU"

PHP error

Fatal error: Allowed memory size of [###] bytes exhausted (tried to allocate [###] bytes) in [path]/[file].php on line [###]

Solution

Increase the PHP configuration setting memory_limit (see the [PHP manual]). After editing the PHP configuration file, you will probably need to restart your webserver. Check your server manual to find out how to do that.

Or

Set php_value memory_limit 32M in the file which will be included in the apache configuration. Like this example:

Alias /squirrelmail /usr/share/squirrelmail

<Directory /usr/share/squirrelmail>
  Options Indexes FollowSymLinks
  <IfModule mod_php4.c>
    php_flag register_globals off
    php_value memory_limit 32M
    php_value post_max_size 8M
    php_value upload_max_filesize 8M
  </IfModule>
  <IfModule mod_php5.c>
    php_flag register_globals off
    php_value memory_limit 32M
    php_value post_max_size 8M
    php_value upload_max_filesize 8M
  </IfModule>
  <IfModule mod_dir.c>
    DirectoryIndex index.php
  </IfModule>

  # access to configtest is limited by default to prevent information leak
  <Files configtest.php>
    order deny,allow
    deny from all
    allow from 127.0.0.1
  </Files>
</Directory>

Solution

Make sure that as much functionality as possible is handled outside PHP (see SquirrelMailPerformance).


Other suggestions

Allowed memory size of XXXX bytes exhausted

If you are trying to download an attachment that was sent to you, but you never can seem to download it all, it might be a good idea to increase PHP's maximum memory limit. Same goes if you ever get the above error message. Look in your php.ini file for the setting "memory_limit" and change it to be a bigger number.

One user reported:

Yes, It's the memory limit (at least it was it for me). I had a memory limit of 8M and the file truncated at 4.xx MB now I changed it to 80M and the whole (8MB) file downloaded without problems.

It's not that we try to consume memory. In fact, we grab a tiny bit of info from the mail server, decode it, send it off to the browser and repeat. We shouldn't be consuming a lot of memory whenever we can avoid it. One place that might need a bit of work is when we forward a message.


Even after fixing /etc/php.ini with memory_limit = 20M and /etc/httpd/conf.d/php.conf LimitRequestBody 20971520 (as described in this section) when tried to forward a message of size 17M, I am getting the following error:

1) when forwarded as attachment:

Fatal error: Allowed memory size of 20971520 bytes exhausted at (null):0 (tried to allocate 17463807 bytes) in /squirrelmail-1.4.5/functions/imap_general.php on line 124

2) When forwarded:

Fatal error: Allowed memory size of 20971520 bytes exhausted at (null):0 (tried to allocate 262144 bytes) in /squirrelmail-1.4.5/functions/imap_general.php on line 241

Note: the difference in the bytes reported when forwarded and forwarded as attachment.

Please let me know the fix for the above stated problem.

Thanks.

wedoitca@yahoo.com


Another user reported:

Don't forget to check your PHP.CONF file

  • NOTE: This file is in the Apache 2.x conf.d directory and is not part of SquirrelMail. The php.ini file is the one that ships with PHP (php.ini is not part of SquirrelMail as previously stated here).

as well, this is where you can get nailed even though you check all the correct options in your php.ini file. You'll want to look at the

# Cause the PHP interpreter handle files with a .php extension.
#
<Files *.php>
    SetOutputFilter PHP
    SetInputFilter PHP
    LimitRequestBody 33554432
</Files>
  • NOTE: Apache 2.x with PHP 4.2 defaults to a LimitRequestBody of 512K which is probably too small.

Section, and change the LimitRequestBody option to something sufficiently large. Otherwise, your browser may throw you back a "HTTP_REQUEST_ENTITY_TOO_LARGE" when you try to attach larger files. The example above is for 32M.

  • NOTE: This is the correct answer in my experience and I am editing this message to try to cut through some of the uncertainty. You have *2* files that control memory in PHP for SquirrelMail, the memory limit in Apache and the one in SquirrelMail. At this time I advise you keep them the same size.
  • Notes added by Dana Bourgeois, Zamples.com, on 2003-08-28

I also got this error message when SquirrelMail couldn't talk to my IMAP server because of a misformed tcpd directive.

David Whitmarsh


I think I got this error because my IMAP server (WU) serves the whole home directory. Hence the problem size in my case was too large for PHP. Changing the memory limit caused the error to happen in different places in the PHP source. Making the memory too large caused a timeout, and the imapd process to take most of the CPU time.

_sham@simpleton.dyn.dhs.org_ (remove the _'s to reply)


This message will also appear in case of not existent mail directory.


When opening folders with many messages I intermittently get the out of memory problem. Other times I can open folders that have 1200 to 1800 messages with no problem at all. It would seem as if there are some serious memory leaks or memory consumption issues.


I get this one when replying to plain text messages, but I can forward... I hope the memory management issue is a top priority. I wouldn't bother adding features until this is worked out, and in my opinion, increasing PHP's memory limit is not a solution, just a temporary workaround.


I got this error due to some bugs in the folders settings whenever I tried to send a message from the compose window. I'm running qmail-ldap/courier-imap/SM2.9 which doesn't allow users to make folders except as subfolders of inbox. To make things more confusing, the config script didn't push new defaults out as it should. Because of this, SM tried to put sent messages into a sent folder that didn't exist even when I thought I had disabled that default. What I finally did to fix the problem was to add the following to ../data/default_pref:

move_to_sent=0
sent_folder=INBOX.SENT
save_as_draft=0
draft_folder=INBOX.DRAFTS
trash_folder=INBOX.TRASH
move_to_trash=0

If a user wants to use trash/sent folders etc. They just have to make a folder and then go to folder options and select that folder as the sent folder to use.

There is also an option in the config script to not allow the option of making a top level folder. This was broken too, so I commented out the choice in src/folders.php:

if ($default_sub_of_inbox == false) {
//    echo '<OPTION SELECTED VALUE="">[ '._("None")." ]\n";
} else {
 //   echo '<OPTION VALUE="">[ '._("None")." ]\n";
}

Everything works peachy now.

-ray ferguson ray_at_share-foo.com


I'm having a problem with downloading attachment bigger than around 1 MB (there?s no real solid "limit") since I upgraded from SquirrelMail 1.2.0 to 1.4.0

Tried increasing the memory_limit from 8M to 50M (which shouldn't matter because 8 MB is "plenty") and that didn?t change a bit.

I have the original unmodified download.php form the original 1.4.0 unmodified (as some plugins do infact require modification of files). I had several plugins (none that seemed to be related to downloading attachment in any way) and disabled them all, still didn't help.

Good thing I had a backup of the 1.2.0 intact, I pointed our webmail url to that folder and now with using 1.2.0 again it works like a charm again.

I was hoping to find someone with the same problem since 1.4.0 but it seems I'm alone. I would investigate it more but my time is limited and I already wasted enough of it today :)

If I ever do find out (can?t be stuck on 1.2.0 forever) what the problem is, I'll update it here

- Jos


Enhancing the memory in php.ini did not help for me either. I went to SquirrelMail's 'configure' program. Selected option 'D' - Set pre-defined settings for specific IMAP servers.

Selected my server. Saved the configuration and exited. Restarted INETD (service xinetd restart) and tested. It worked for me.

- Kewl Mike


This was a constant, major problem where I work. After doing a lot of analysis we discovered the IMAP server (Courier IMAP + qmail) was the cause of the problem by limiting the maximum number of connections per IP that it allowed to four. When the server load got over 4 concurrent users it would start coming up with fatal error; this more frequently happened when the load of either the webmail server or IMAP server went high enough that each request was slowed down.

For those people having problems with this, check this setting. It would be nice to allow unlimited connections from our webmail IP(s) and limit for all other addresses. Currently we are using MAXPERIP=16 and the problems appear to have gone away.

- Trevor


We have the same problem as many other users: downloading attachments greater than 1 MB is not possible.

We use:

- Debian Linux 3.X

- UW IMAP

- Apache 1.3X / PHP 4.X

(all latest stable versions)

- SM 1.42

We tried all possible solutions described on this site and nothing worked. Does anybody have an idea what to do to get working SM again? Does anybody know what the caoders of SM think about this problem? Think many users have this problem, because attachments with 1 MB (and more) are sent often!

- Hans


Was getting this same message on opening large IMAP folders. Cyrus IMAP on Debian. Changing the memory_limit to 80M and restarting apache appears to have remedied the problem. Many thanks.

Derek


I was getting the same problem. I too tried to up the memory in my php.ini file to 80M and it still didn't work. I was able to get it to work by fixing my /etc/hosts.allow file. My POP3 and IMAP listings were incorrect. I also added INBOX.Drafts, INBOX.Sent and INBOX.Trash to each users home directory. If you connect to the server with a e-mail program like Outlook it will create the folders for you.

Kendell


I didn't catch this right away, but make sure you restart apache after modifying php.ini otherwise it will still use the old setting.

Joe


The Compose message window would not parse correctly and I saw this error message in the log:

Allowed memory size of 8388608 bytes exhausted (tried to allocate 44 bytes)

I changed the memory_limit = 8M parameter in php.ini to memory_limit = 32M, restarted apache and that worked. I am a bit mystified why it started showing up after 3 years of smooth execution.

James 2005-10-08


In a virtual hosting environment I want to increase memory allocation to SquirrelMail only - changing the settings in the main php.ini file is not an option since it would let every customer's script allocate that much memory and wreck havoc on the system.

With Apache, php.ini parameters can be set individually for every directory. To do so, add a file named .htaccess in each directory containing scripts that require more than the standard memory allocated in php.ini. .htaccess will read something like: php_value memory_limit "32M".

Other php.ini parameters can be changed with the same syntax.

Then add to the Apache configuration file httpd.conf the following directive:

<Directory "/usr/local/path/to/squirrelmail">
    AllowOverride All
</Directory>

I am just not sure which SquirrelMail directories are affected. Is this only the src directory? or the plugins as well? I have not enough understanding of SquirrelMail to know.

- Yuv 2005-11-06 yuval(under_score)levy/at/yahoo*dot*com


"Allowed memory size of 8388608 bytes exhausted (tried to allocate 140 bytes)"

I moved our mailserver from RHEL 3 to RHEL 4 and noticed this error in testing. Specifically, I could not click on a message that contained a 1.8M jpg attachment. (Note that I did not try to view the attachment, just the message.) Clicking on the message brought me to a blank frame, and when I checked the apache logs, I found the above error.

In the /etc/php.ini file I changed memory_limit to 16M (was previously 8M), restarted apache (/etc/init.d/apache restart), and the problem went away.

I am using uw-imap, and the folder in question was the INBOX in mbx format.

- Joel thras/at/nmt.edu


This error may also be caused by setting option $allow_server_sort to false in config.php

If server supports server-side sorting, this option DEFINITELY should be switched to "true" - speeds up squirrelmail vastly, and makes it possible to view folders containing thoulsands of messages (what would otherwise need you to extend both allowed memory usage and maximum execution time in PHP).

- 2008-10-3 joshua/at/silvercube/dot/pl


This last piece of advice worked for me. Thanks Joshua. Rob 10-7-08


Delete my pref account, certainly corrupted, in /var/db/squirrelmail/data/ solved this problem, in my case.


Disconnect from account.

In the file .../data/<myaccount>.pref, remove the line:

security_tokens=<long list...>

edit the line "sort=0", change for "sort=6"

reconnect

all was good again.

© 1999-2010 by The SquirrelMail Project Team