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! -->Laura Gasslein
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 chunks. 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
