Description:
------------
The strtotime() function still leaks memory in patched PHP 5.2.8 after applying patches from http://news.php.net/php.cvs/55000. The memory leak itself is much smaller than before applying fixes. Before, it took a few seconds to leak 1gb of mem, now it takes some minutes however it's still there.
This bug is related to http://bugs.php.net/bug.php?id=46889.
Reproduce code:
---------------
while (true)
{
$tmp = inc_stamp(time(), 1);
}
function inc_stamp($timestamp, $off_days)
{
return strtotime("+" . $off_days . " day", $timestamp);
}
Actual result:
--------------
Memory leak reported by top(1). If the script runs for longer time, it gets killed by kernel since the system is going out of memory and swap.

Like I said, I can not reproduce this. But please test without xcache being loaded!

[2009-02-05 12:09 UTC] danger at FreeBSD dot org

root@[temp ~]# php -v
PHP 5.2.9-dev (cli) (built: Feb 5 2009 13:04:42)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
still leaks. If you are interested in access to that box to debug, I will be glad to provide you with the login credentials.

I am not forgetting about this, but at the moment just really occupied. Just as a quick question, this is the *stock* PHP without any ports patches, also, if you set the error level to also show e_Strict messages, do you see anything? Also, do you have the date.timezone setting made in PHP.ini?

[2009-02-27 13:25 UTC] danger at FreeBSD dot org

Hey there,
I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything else) with ./configure && make.
When I run my test script as this:
root@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php /root/test.php
No modified php.ini is being used, no additional extensions are being loaded. I can still verify that it leaks.

[2009-02-27 13:53 UTC] danger at FreeBSD dot org

I tried to run my script with php -d error_reporting=E_STRICT test.php and been receiving this error until I stopped the script:
Strict Standards: strtotime(): It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line 10

[2009-02-27 14:48 UTC] maarten at vivesta dot com

Same here. I've added a date_default_timezone_set() before using
strtotime() and it removed the error but not the leak.

Sorry for being dumb but does this leak affect memory_limit ? I mean, I can reproduce the memleak with Linux and PHP 5.2.9 but memory_get_usage() output seems constant, although memory occupied by the process itself is getting biger every second, so there's clearly a memleak.
I ask this because I don't know if there is an actual relationship between this bug and some strange cronjob deaths I'm experiencing with PHP 5.2.9.
TIA

[2009-04-15 07:55 UTC] kimc at operamail dot com

You dont see the memory leak with PHP's memory_get_usage(), and the process wont get killed by PHP's general memory_limit.
PHP doesnt see the memory use, but the kernel does and after some time the kernel will kill it due to ulimit or out of memory.

[2009-07-07 10:47 UTC] oliver at realtsp dot com

I can confirm that we can reproduce this bug on FreeBSD 7.2 with php5.2.10 and that the patch provided by bloudon at townnews dot com does stop the leak.
I had to manually apply the patch because copying out of the html rarely works, so I have prepared a "clean" version which applies without errors to the current FreeBSD 7.2 port of php5. Here it is:
http://www.realtsp.com/public/patch-ext_date_php_date.c
Oliver

I can confirm the same leak, running in Apache on Windows. Apache kills the script after a time limit, but the leaked memory remains leaked; refreshing the same URL causes the total leaked memory to increase from there. It looks like it leaks 800KB per second or so, and the script is killed after leaking about 30MB.
I'm running PHP 5.2.9-2, which came straight from the default Windows installer.