Last modified: 2010-05-15 15:33:12 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1509 - config/index.php line 244- memlimit check faulty if memory_limit set to -1 in /etc/php.ini - causes rebuildall to fail
config/index.php line 244- memlimit check faulty if memory_limit set to -1 in...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.4.x
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-10 22:36 UTC by Laura G
Modified: 2010-05-15 15:33 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Laura G 2005-02-10 22:36:04 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
Comment 1 Brion Vibber 2005-02-10 22:49:52 UTC
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.
Comment 2 Brion Vibber 2005-03-27 02:23:52 UTC
1.4.0 released; kicking back to 1.5 blockers.
Comment 3 JeLuF 2005-04-26 20:02:53 UTC
Fixed in config/index.php, rev 1.114

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links