#2934 (ok 3.2.3) Document side effects of MemoryLimit setting
After some research on why all recent phpMyAdmin version returned blank pages after executing SQL queries or refreshing pages, I have found the following:
PHP borked on a very small memory_limit when executing queries and refreshing pages because /scripts/setup.php uses a faulty default value for memory_limit on at least v2.11.9.6. The default value is the integer 32, which is translated by PHP to a memory limit of 32 bytes, a unusable default value.
Commenting the line in the config or chancing the value to the string '32M' made the problems disappear.
Also, the documentation states that the memorylimit configuration option is only used when importing and exporting data, I believe that to be faulty as well.
In short:
- /scripts/setup.php uses a faulty default value for memory_limit on at least v2.11.9.6.
- I couldn't find setup.php on 3.2.2.1 but those versions may also be affected.
- The problem might go back to when the setting memorylimit was included in the source.
- The documentation is unclear on where the defined memory limit is actually used. Only when importing and exporting, or also when executing queries and refreshing pages?
My recommendations:
- setup.php, if included, should provide a form that allows the memory limit to be set. Although I've made several configurations using setup.php, I was never aware of any configured memory limit.
- According to the documentation the memorylimit option is an integer in bytes, but the example of "16M" might lead users to conclude that the integer 16 would be a usable value. My suggestion would be to add a clear example: "the integer 33554432 for a limit of 32 megabytes".
More on this and how I got to this particular problem can be found here:
https://sourceforge.net/projects/phpmyadmin/forums/forum/72909/topic/3321122
Discussion
If you search thru the code of 2.11.9.6 you'll see that $cfg['MemoryLimit'] is only used in importing and exporting, so the doc is correct in this regard.
Also, I don't see anywhere in scripts/setup.php of 2.11.9.6, that this script would generate this MemoryLimit parameter in the configuration file. Maybe I'm blind.
I suspect that the "32" value did not come from scripts/setup.php.
I don't see why the "16M" example would lead a user to conclude he should use "16".
I tested by setting
$cfg['MemoryLimit'] = 32;
in my config.inc.php of version 2.11.9.6 and it's true that there is a problem. This is because import.php is called when you click Refresh.
Fixed in subversion, thanks for reporting.
I'm sorry I was unable to respond to your replies earlier.
Thank you for fixing the parts of this bug that you where able to confirm. Is it true that this also fixes the problem when just executing a SQL query instead of refreshing? I did mention it shortly in my report, but perhaps it was overlooked - just checking. Both actions produce the same error in my error_log.
My suggestions for changes in the documentation are partly based on that people are uncareful when reading sometimes. Seeing the integer 0 as the default configuration option and catching a glimpse of the '16M' example may lead one to skip reading the actual sentence and/or believe the M is a typo and then assume the integer 16 is a valid, realistic value.
Also, I think that most people are interested in setting the value in megabytes instead of bytes. On modern systems there's no real use for setting the maximum memory usage byte precise.
When using the string '32M' it's a little bit easier to set a new value and also very easy to see what type of units I should read the value in without looking it up in the documentation.
With that in mind, I would recommend to change the example in the documentation to a string value and then suggest the integer for setting it byte precise as a good second option instead of the opposite.
The absence of anything related to $cfg['MemoryLimit'] in setup.php is indeed a very good point. That's why I've done some additional research as to why $cfg['MemoryLimit'] has somehow appeared in my configuration. I mistakenly assumed that it was inserted by setup.php, my bad.
In short, I was unable to find the exact cause, but I now agree it's very likely the problem was not caused by phpMyAdmin or setup.php.
(Read on for a little more details)
In my search I have considered several scenario's including user error. There are several reasons that would indicate user error, and several that indicate problems outside phpmyadmin.
For example, the configuration in which I noticed the problem first doesn't have it's configuration options sorted alphabetically, while setup.php (I believe) does always sort the options that way.
It's possible I've copied a configuration of a earlier version of phpMyAdmin I used. It came from the Gentoo Linux portage tree. I'm very certain that I've created a configuration with setup.php as well, but perhaps I just imported a file containing $cfg['MemoryLimit'] to setup.php to start with some important values.
I've checked the configuration I used with the phpMyAdmin from Gentoo but it doesn't have the MemoryLimit option.
Well. The origin will perhaps remain a mystery forever.
"just executing a SQL query" ... well it depends on the method you use to execute the SQL query.
In case you haven't seen it yet, the new documentation is now:
$cfg['MemoryLimit'] integer [number of bytes]
Set the number of bytes a script is allowed to allocate. If set to zero, no limit is imposed.
This setting is used while importing/exporting dump files and at some other places in phpMyAdmin so you definitely don't want to put here a too low value. It has no effect when PHP is running in safe mode.
You can also use any string as in php.ini, eg. '16M'. Ensure you don't omit the suffix (16 means 16 bytes!)