ID: 47285 Comment by: kimc at operamail 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:
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. Previous Comments: ------------------------------------------------------------------------ [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) { ------------------------------------------------------------------------ [2009-03-09 21:41:58] martin at 925 dot dk Removing UTC from the timestamp in php_date.c also fixes the leak: --- php_date_.c 2009-03-09 22:30:15.000000000 +0100 +++ php_date.c 2009-03-09 22:30:21.000000000 +0100 @@ -1117,7 +1117,7 @@ now = timelib_time_ctor(); initial_ts = emalloc(25); - snprintf(initial_ts, 24, "@%ld UTC", preset_ts); + snprintf(initial_ts, 24, "@%ld", preset_ts); t = timelib_strtotime(initial_ts, strlen(initial_ts), NULL, DATE_TIMEZONEDB); /* we ignore the error here, as this should never fail */ timelib_update_ts(t, tzi); now->tz_info = tzi; ------------------------------------------------------------------------ [2009-03-09 18:46:22] martin at 925 dot dk This patch (which reverts the fix for bug 45529) against parse_date.c seems to fix the leak: Hence this patch against parse_date.c: --- parse_date_.c 2009-03-09 19:33:37.000000000 +0100 +++ parse_date.c 2009-03-09 19:33:45.000000000 +0100 @@ -733,7 +733,7 @@ } #endif /* If we have a TimeZone identifier to start with, use it */ - if (strstr(tz_abbr, "/") || strcmp(tz_abbr, "UTC") == 0) { + if (strstr(tz_abbr, "/")) { if ((res = timelib_parse_tzfile(tz_abbr, tzdb)) != NULL) { t->tz_info = res; t->zone_type = TIMELIB_ZONETYPE_ID; ------------------------------------------------------------------------ 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