Last modified: 2010-05-15 15:33:12 UTC
After installing, I went to the config page (config/index.php) by following a link to configure my
wiki as instructed. I entered in the data as requested (db user, sysop account, etc.)
After submitting the form, a check is done on the memory_limit INI variable in /etc/php.ini... I had
this variable set to -1 (which means give PHP unlimited memory.) This check, which occurs starting
at line 244 of config/index.php, determines if the memory_limit is greater than 20 MB. If not, then
these two things occur: ini_set( "memory_limit", "20M" ) AND $conf->raiseMemory = true; - the second
line writes to the LocalSettings.php file.
Now, when I went to run rebuildall.php to get my links up to date, rebuildall.php will always fail
because it reads LocalSettings.php (via inclusion of commandLine.inc) to get the value of the
memory_limit INI variable. The value during execution of rebuildall.php will be 20M, (because of
line 12 - "ini_set( 'memory_limit', '20M' );" - in LocalSettings.php, written during
configuration)... and 20M is NEVER enough to run rebuildall.php - it will die with "Fatal error:
Allowed memory size of x bytes exhausted at x (tried to allocate 43 bytes)"- where the first x is 20
MB. I have found that for the current database dump, the cur table has almost 1.5 million records
and at least 300MB is required.
It took me a while to track this down. I know it's unusual to have memory_limit set to -1
in /etc/php.ini, but the config/index.php code should account for that possibility anyway. I do not
want my memory limit to be 20 MB for rebuildall.php, I want it to be unlimited. I think the problem
could be solved by just adding a case into config/index.php that checks for the special case of
unlimited memory (-1), instead of just checking that the value of memory_limit is not empty, and
that it is greater than 20MB.
Thanks for your time!
You're right, we should be checking for -1. Adding to 1.4 release blockers...
Separately, we really _shouldn't_ be ballooning to 300 megabytes (even if 20 isn't
enough, 300 seems like waayyyyy too much). Probably either a) we have a memory leak
or b) something is fetching every record at once when it should be working in smaller
Can you check which part of the rebuild process is eating up the memory? Its
components are callable as separate scripts too, so try them individually if it's not clear
from watching memory usage while it runs.
1.4.0 released; kicking back to 1.5 blockers.
Fixed in config/index.php, rev 1.114