PHP: Allowed memory size exhausted

The indieweb.org wiki has a page about Wordpress with a Criticism section. ​

One of those "issues" listed is Fatal Error memory exhausted, which reads so: ​

WordPress seems to run out of memory on servers sometimes, and give a message like: ​

e.g. on http://yottabytes.info/?p=10497 (on 2014-06-08 15:28 EDT): ​

Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 32 bytes) in /home/johnkrol/public_html/wp-includes/post.php on line 1961 ​
​

I removed that section because it's nonsense to list a server configuration issue as Criticism. ​

Yesterday Tantek reverted it because: ​

worth keeping actual error seen in the wild as a known issue until evidence presented that it's been fixed in an update, actual fail 32 bytes ​

This forces me to issue a personal statement: ​

Dear Tantek, please try to acceptexplore the idea that others know a thing or two that you don't. ​

Error explanation​

What does this error actually mean? ​

Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 32 bytes) in /path/to/file.php on line 1961 ​

PHP allows you to hard-limit the RAM that PHP applications are allowed to use. The setting is called memory_limit, and it is configured in your web server's php.ini file. ​

When the code that is run by PHP needs to allocate memory - for example when a new variable is initialized - then PHP checks how much memory that variable needs, and if the currently used memory plus the new variable is with the configured memory_limit. ​

If the new memory allocation would exceed that limit, PHP simply adheres to its configuration and says "Sorry, I can't do that" but in other words: ​

Fatal error: Allowed memory size of XXX bytes exhausted ​

The limit that Tantek saw was 41943040, which is - when divided by 1024 twice - exactly 40 MiB. Thus we can assume that johnkrol's server had the following php.ini setting: ​

memory_limit = 40M

The fact that this error was raised when WordPress tried to initialize a variable of 32 bytes is irrelevant here. ​

Written by Christian Weiske.

Comments? Please send an e-mail.