I had a little hiccup when I installed D7RC3 on a test site today. After showing the status bar at 100% or so (the last thing I saw under it was standard module) I got a HTTP 500 error.
I checked the logs and saw a PHP error:

PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 24 bytes) in /mnt/stor1-wc1-dfw1/380423/401424/www.rantastic.net/web/content/drupal-7.0-rc3/includes/theme.inc on line 965

Since the system requirements documentation for D7 states:

PHP memory requirements can vary significantly depending on the modules in use on your site. Drupal 6 core requires PHP's memory_limit to be at least 16MB, and Drupal 7 core requires 32MB. Warning messages will be shown if the PHP configuration does not meet these requirements. However, while these values may be sufficient for a default Drupal installation, a production site with a number of commonly used modules enabled (CCK, Views etc.) could require 64 MB or more.

My PHP system was set to allow 32MB, and I did not receive any errors indicating insufficient memory, I would have expected the installation to complete without a PHP memory error.

The solution is trivial (I just added php_value memory_limit 48M to my .htaccess file) but I don't think it should have happened in the first place. (Where was the warning?)

Regards,
Mark

Comments

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Priority: Minor » Normal

Are you sure you only installed using the standard profile, with no extra modules?

I just tried it and was able to install with 32MB with no problems. I put in some quick logging to double check how much memory was being used, and the peak was around 26 MB (similar to what I saw last time it was profiled, which was at #281405-157: Drupal 7.x can't be installed with memory_limit=32M).

I guess it could vary from server to server, but that seems like a big difference. Strange.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

Hm, it looks like the code yours failed on, line 965 of includes/theme.inc, was this (the "get_defined_functions" part):

function drupal_find_theme_functions($cache, $prefixes) {
  $implementations = array();
  $functions = get_defined_functions();

The number of defined functions is definitely something that could vary between PHP installations. I wonder by how much.

Do you have a large number of PHP extensions and such installed on this server? We may have to try debugging to see the size of the array returned by that function...

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Status: Needs review » Active

There is no patch here, so I'm setting this back to "active".

mschaffer’s picture

mschaffer CreditAttribution: mschaffer commented

In reply to the post by David_Rothstein on December 28, 2010 at 12:20am:

I am sure. I started from scratch with the RC3 tar.gz file. I only selected the standard install profile. No extra modules existed in the directories. I was running this on the Laughing Squid Cloud Hosting (Ultra Squid service). The systems are running PHP 5.2.13 and MySQL 5.0.77.

The only reason I mentioned this is because the documentation specifically states that there was a check.
The fix may be to change the documentation to reflect this is a possibility and the memory check may fail.

mschaffer’s picture

mschaffer CreditAttribution: mschaffer commented

In reply to the post by David_Rothstein on December 28, 2010 at 12:24am:

I don't know what "a large number of PHP extensions and such" would be. It's running on Laughing Squid's cloud based service, so it is what it is. Anyhow, here's what print_r(get_loaded_extensions()); yieds:

Array ( [0] => date [1] => libxml [2] => openssl [3] => pcre [4] => zlib [5] => bz2 [6] => calendar [7] => ctype [8] => hash [9] => filter [10] => ftp [11] => gettext [12] => gmp [13] => session [14] => iconv [15] => mime_magic [16] => Reflection [17] => standard [18] => shmop [19] => SimpleXML [20] => SPL [21] => sockets [22] => SQLite [23] => exif [24] => tokenizer [25] => xml [26] => apache2handler [27] => bcmath [28] => curl [29] => dba [30] => dbase [31] => dom [32] => gd [33] => imagick [34] => imap [35] => json [36] => ldap [37] => pdf [38] => mbstring [39] => mcrypt [40] => memcache [41] => mhash [42] => mssql [43] => mysql [44] => mysqli [45] => ncurses [46] => odbc [47] => PDO [48] => pdo_dblib [49] => pdo_mysql [50] => PDO_ODBC [51] => pdo_pgsql [52] => pdo_sqlite [53] => pgsql [54] => pspell [55] => snmp [56] => soap [57] => sybase_ct [58] => tidy [59] => uploadprogress [60] => wddx [61] => xmlreader [62] => xmlrpc [63] => xmlwriter [64] => xsl [65] => yaz [66] => zip [67] => ionCube Loader [68] => Zend Optimizer )

Is that a lot? What other things could bloat the memory usage other than the PHP extensions?

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Priority: Normal » Major

Could we maybe do this on a few different installs to compare?

$foo = get_defined_functions();
print_r(count($foo['internal']));
print_r(count($foo['user']));

Also your server doesn't appear to be running APC, so that could bump the memory usage up a fair bit.

Bumping this to major since if sufficient hosting environments run into this we will likely need to put the requirement up.

mschaffer’s picture

mschaffer CreditAttribution: mschaffer commented

In reply to catch on December 30, 2010 at 12:12am

print_r(count($foo['internal'])); yields 4484
print_r(count($foo['user'])); yields 0

Riaan Burger’s picture

Riaan Burger CreditAttribution: Riaan Burger commented

$foo = get_defined_functions();
print_r(count($foo['internal']));
print_r(memory_get_peak_usage());

Home with XAMPP(Win)
1766
517632

A Production Debian Server
1615
298860

Added this after line 965 in includes/theme.inc

$peak = memory_get_peak_usage();
watchdog('theme', '@peak memory.', array('@peak' => $peak), WATCHDOG_WARNING);

Highest reported memory usage during standard install:

Home with XAMPP(Win): 21725624
A Production Debian Server: 21315264

Does the difference in differences (218772 for the first test and 410360 for the second) mean we should investigate more than just get_defined_functions()?

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Title: PHP memory install problem » 32M is sometimes not enough memory to install Drupal 7
Version: 7.0-rc3 » 7.x-dev

Another (possible) report of this problem here: http://drupal.org/node/951644#comment-4000888

For what it's worth, when I tried:

$foo = get_defined_functions();
print_r(count($foo['internal']));

I got:

1437

Which is similar to what @Riaan Burger saw, but way less than the number reported by @mschaffer.

So it seems likely that the number of PHP extensions/functions on @mschaffer's setup are putting it over the limit. I haven't looked through that list carefully, but if it's a common enough setup, I guess we'll indeed need to increase the limit higher than 32M :(

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

get_defined_functions() is just the last function to get called before exceeding memory limit (and at 2-400kb it's probably enough to send things over the limit by itself), but there might be other things going on as well.

You can get memory usage information with xhprof and xdebug, but doing so is going to be impossible on systems that can't just raise the memory limit anyway, and it's a bit of a pain profiling batch. I know carlos8f did some serious work on profiling the installer, will try to point him to this issue since he might have ideas on the easiest way to collect this.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented
Status: Active » Postponed (maintainer needs more info)

We need more information here.

If you're unable to install with 32M, please do the following:

1. Post up here with the error message so we can see which function it craps out on.

2. Bisect the memory limit that you're actually able to install with, for example:

32 - no
48 - yes
40 - no
44 - yes
42 -yes
41 yes

3. Upload a .txt file with the output from phpinfo(), and also say which host you're on.

Then we can either raise the memory requirement, or see if there's anywhere to cut down memory usage quickly in D7 for the installer depending how far over the 32M it really is.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Priority: Major » Normal
fgm’s picture

fgm
Primary language French
Location Paris, France
CreditAttribution: fgm commented

1582 internal functions here on a dev system.

The configuration shown at #5 contains quite a number of usually unneeded extensions:

- gmp
- dba
- dbase (!)
- pdf
- ncurses
- wddx
- xmlrpc : completely rewritten by Drupal in user space

Others tend to be only used in enterprise settings where going over 32 MB won't be a problem anyway:
- ldap
- memcache
- mssql
- odbc
- snmp
- soap
- sybase_ct
- yaz

And finally, are know to cause a number of issues and possible interferences with Drupal:

- ionCube Loader
- Zend Optimizer: used to cause segfaults in db_query_backtrace(), for instance.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

No response from OP, closing.