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: Mac OS X 10.5
PHP Version: 5.3.0beta1
Assigned To: derick
New Comment:
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;
Previous Comments:
------------------------------------------------------------------------
[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
