#47285 [Com]: strtotime() still leaks memory

 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:

The last patch fixes the memory leak for me.


Previous Comments:
------------------------------------------------------------------------

[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",
&times, &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;

------------------------------------------------------------------------

[2009-02-27 14:48:14] 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.

------------------------------------------------------------------------

[2009-02-27 13:53:29] 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

------------------------------------------------------------------------

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