ID: 47285
Comment by: scott at crisscott dot com
Reported By: danger at FreeBSD dot org
Status: Assigned
Bug Type: Date/time related
Operating System: FreeBSD
PHP Version: 5.2.8
Assigned To: derick
New Comment:
Reproduced on RHEL 4 (PHP built from source not RPM)
PHP 5.2.9 (cli) (built: May 1 2009 13:47:24)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Debugger v5.2.14, Copyright (c) 1999-2008, by Zend
Technologies
Applying the patch from oliver at realtsp dot com slowed down the leak,
but did not stop it entirely.
Previous Comments:
------------------------------------------------------------------------
[2009-07-07 10:47:47] 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
------------------------------------------------------------------------
[2009-04-15 07:55:33] 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-04-06 10:01:32] davide dot ferrari at atrapalo dot com
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-03-30 12:25:48] kimc at operamail dot com
The last patch fixes the memory leak for me.
------------------------------------------------------------------------
[2009-03-11 15:36:05] bloudon at townnews dot com
Leak also observed in 5.2.8 and 5.2.9 on Linux.
This patch (against 5.2.9) is working out for us so far in our dev
environment:
--- ext/date/php_date.orig.c 2009-03-11 10:07:36.000000000 -0500
+++ ext/date/php_date.c 2009-03-11 10:12:40.000000000 -0500
@@ -1108,7 +1108,7 @@
long preset_ts, ts;
timelib_time *t, *now;
- timelib_tzinfo *tzi;
+ timelib_tzinfo *tzi, *old_tzi;
tzi = get_timezone_info(TSRMLS_C);
@@ -1119,10 +1119,14 @@
initial_ts = emalloc(25);
snprintf(initial_ts, 24, "@%ld UTC", preset_ts);
t = timelib_strtotime(initial_ts, strlen(initial_ts), NULL,
DATE_TIMEZONEDB); /* we ignore the error here, as this should never fail
*/
+ old_tzi = t->tz_info;
timelib_update_ts(t, tzi);
now->tz_info = tzi;
now->zone_type = TIMELIB_ZONETYPE_ID;
timelib_unixtime2local(now, t->sse);
+ if ( old_tzi ) {
+ timelib_tzinfo_dtor(old_tzi);
+ }
timelib_time_dtor(t);
efree(initial_ts);
} else if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s|l",
×, &time_len, &preset_ts) != FAILURE) {
@@ -1141,6 +1145,7 @@
}
t = timelib_strtotime(times, time_len, &error, DATE_TIMEZONEDB);
+ old_tzi = t->tz_info;
error1 = error->error_count;
timelib_error_container_dtor(error);
timelib_fill_holes(t, now, TIMELIB_NO_CLONE);
@@ -1148,6 +1153,9 @@
ts = timelib_date_to_int(t, &error2);
timelib_time_dtor(now);
+ if ( old_tzi ) {
+ timelib_tzinfo_dtor(old_tzi);
+ }
timelib_time_dtor(t);
if (error1 || error2) {
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47285
--
Edit this bug report at http://bugs.php.net/?id=47285&edit=1
