ID: 47351
Comment by: tobias dot john at fondsnet dot de
Reported By: tobias dot john at fondsnet dot de
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.*, 6CVS (2009-05-11)
Assigned To: derick
New Comment:
Here is the patch for RC4. It would be nice if this makes it in before
final, because this bug basically makes \DateTime more or less unuseable
in longer running processes and processes that create and destroy many
DateTime objects (like imports).
--- php-5.3.0RC3.orig/ext/date/php_date.c 2009-05-31 23:28:38.000000000
+0200
+++ php-5.3.0RC3/ext/date/php_date.c 2009-06-15 09:28:03.000000000
+0200
@@ -2401,7 +2401,7 @@
}
timelib_unixtime2local(now, (timelib_sll) time(NULL));
- timelib_fill_holes(dateobj->time, now, 0);
+ timelib_fill_holes(dateobj->time, now, TIMELIB_NO_CLONE);
timelib_update_ts(dateobj->time, tzi);
dateobj->time->have_relative = 0;
Previous Comments:
------------------------------------------------------------------------
[2009-05-07 10:06:27] tobias dot john at fondsnet dot de
I use this patch for 5.3.0RC1.
--- php-5.3.0RC1/ext/date/php_date.c 2009-01-27 14:48:10.000000000
+0100
+++ php-5.3.0RC1patched/ext/date/php_date.c 2009-05-07
10:54:48.000000000 +0200
@@ -2362,7 +2362,7 @@
}
timelib_unixtime2local(now, (timelib_sll) time(NULL));
- timelib_fill_holes(dateobj->time, now, 0);
+ timelib_fill_holes(dateobj->time, now, TIMELIB_NO_CLONE);
timelib_update_ts(dateobj->time, tzi);
dateobj->time->have_relative = 0;
------------------------------------------------------------------------
[2009-03-11 15:29:23] bloudon at townnews dot com
This patch against 5.2.9 seems to be working out for us so far:
--- ext/date/php_date.orig.c 2009-03-10 15:02:40.000000000 -0500
+++ ext/date/php_date.c 2009-03-10 15:02:57.000000000 -0500
@@ -1737,7 +1737,7 @@
}
timelib_unixtime2local(now, (timelib_sll) time(NULL));
- timelib_fill_holes(dateobj->time, now, 0);
+ timelib_fill_holes(dateobj->time, now, TIMELIB_NO_CLONE);
timelib_update_ts(dateobj->time, tzi);
dateobj->time->have_weekday_relative = dateobj->time->have_relative
= 0;
------------------------------------------------------------------------
[2009-03-05 17:39:39] bloudon at townnews dot com
Same bug found in PHP versions 5.2.8 and 5.2.9 on Linux.
-----
Test code:
for ( $i = 0; $i < 100; $i++ ) {
$d = new DateTime();
unset($d);
}
-----
valgrind --leak-check=yes php test.php:
==20642== 235 bytes in 1 blocks are possibly lost in loss record 4 of
12
==20642== at 0x40203C0: malloc (vg_replace_malloc.c:149)
==20642== by 0x80AB486: timelib_tzinfo_clone (in /usr/bin/php)
==20642== by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20642== by 0x8095535: (within /usr/bin/php)
==20642== by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20642== by 0x817D834: (within /usr/bin/php)
==20642== by 0x819ED4F: execute (in /usr/bin/php)
==20642== by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20642== by 0x813862F: php_execute_script (in /usr/bin/php)
==20642== by 0x81A7178: main (in /usr/bin/php)
==20642==
==20642==
==20642== 2,820 bytes in 3 blocks are possibly lost in loss record 8 of
12
==20642== at 0x40203C0: malloc (vg_replace_malloc.c:149)
==20642== by 0x80AB47A: timelib_tzinfo_clone (in /usr/bin/php)
==20642== by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20642== by 0x8095535: (within /usr/bin/php)
==20642== by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20642== by 0x817D834: (within /usr/bin/php)
==20642== by 0x819ED4F: execute (in /usr/bin/php)
==20642== by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20642== by 0x813862F: php_execute_script (in /usr/bin/php)
==20642== by 0x81A7178: main (in /usr/bin/php)
==20642==
==20642==
==20642== 132,845 (4,800 direct, 128,045 indirect) bytes in 100 blocks
are definitely lost in loss record 9 of 12
==20642== at 0x401F6FF: calloc (vg_replace_malloc.c:279)
==20642== by 0x80AB420: timelib_tzinfo_ctor (in /usr/bin/php)
==20642== by 0x80AB446: timelib_tzinfo_clone (in /usr/bin/php)
==20642== by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20642== by 0x8095535: (within /usr/bin/php)
==20642== by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20642== by 0x817D834: (within /usr/bin/php)
==20642== by 0x819ED4F: execute (in /usr/bin/php)
==20642== by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20642== by 0x813862F: php_execute_script (in /usr/bin/php)
==20642== by 0x81A7178: main (in /usr/bin/php)
-----
Setting a default time zone through date_default_timezone_set() or
putenv() changes the leak to:
==20819== 7,600 (4,800 direct, 2,800 indirect) bytes in 100 blocks are
definitely lost in loss record 10 of 10
==20819== at 0x401F6FF: calloc (vg_replace_malloc.c:279)
==20819== by 0x80AB420: timelib_tzinfo_ctor (in /usr/bin/php)
==20819== by 0x80AB446: timelib_tzinfo_clone (in /usr/bin/php)
==20819== by 0x8097FD3: timelib_fill_holes (in /usr/bin/php)
==20819== by 0x8095535: (within /usr/bin/php)
==20819== by 0x8095605: zim_DateTime___construct (in /usr/bin/php)
==20819== by 0x817D834: (within /usr/bin/php)
==20819== by 0x819ED4F: execute (in /usr/bin/php)
==20819== by 0x8166F25: zend_execute_scripts (in /usr/bin/php)
==20819== by 0x813862F: php_execute_script (in /usr/bin/php)
==20819== by 0x81A7178: main (in /usr/bin/php)
------------------------------------------------------------------------
[2009-02-23 13:49:09] paul dot assen at xs4all dot nl
I found this bug also to be present in PHP 5.2.8 under Windows XP
------------------------------------------------------------------------
[2009-02-10 09:14:49] tobias dot john at fondsnet dot de
Description:
------------
Memory allocated by a DateTime object is not released correctly.
Inifite loops of allocating DateTime objects let the memory consumption
even raise above the php memory limit.
Reproduce code:
---------------
while(1) {
$v = new \DateTime();
}
Expected result:
----------------
Infinite loop.
Actual result:
--------------
php(38699) malloc: *** mmap(size=16777216) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Bus error
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=47351&edit=1
