WordPress changes PHP's memory_limit but doesn't change it back

[jmstacey]

WordPress? changes the memory limit using ini_set(...) several times but does not undo the changes after the tests have run. This can lead to running out of memory when running PHPUnit. PHPUnit does not reset any ini values to the best of my knowledge, so we should reset the memory limit in the test suite tearDown. For example, the following tearDown() function in wp-testlib/base.php fixes the problem:

function tearDown() {
	if (!is_null($this->_old_handler)) {
		restore_error_handler();
	}
	_enable_wp_die();
		
	ini_set('memory_limit', '-1');
}

In the real fix it would probably be wise to set the memory limit to whatever it was at the start of execution (before WordPress? is loaded)--which means the value in php.ini. The memory limit of '-1' means unlimited but I do not know if this is effective on version of PHP prior to 5.3.

I submitted PHPUnit bug 1080 here: ​http://www.phpunit.de/ticket/1080
It's in our immediate interests to fix this on our end and unlikely to harm long-term goals.

I just attached memory_limit_patch.diff which contains a possible fix that seems to do the trick for me.

This one actually works. Apparently WP occasionally resets memory limit to an empty string and so the original memory limit was forgotten in the last patch.

Some useful Information:

• ini_set('memory_limit', '-1'); removes any memory limit.
• ini_restore('memory_limit'); restores the original value.

So the patch can be adopted to make use of the ini_restore() function as this is the function intended to do what's aimed for.

Related: ​http://core.trac.wordpress.org/ticket/13847

This works for me. I cannot run WP unit tests without better_memory_limit_fix.diff​.

WordPress? sometimes changes the memory limit to 256M, but this is now a WP_MAX_MEMORY_LIMIT constant. We should just set both WP_MEMORY_LIMIT and MAX to -1 and we'll be good to go. (Also requires ​[WP21165] for maximum effectiveness.)

(In [876]) Set tests memory_limit to -1. Any changes by core use these constants. We can consider adding it to tearDown() at some point in the future. fixes #6.