Bug #66091 [Com]: Memory leak in DateTime::createFromFormat()
| From: | nurlan0000 at gmail dot com | Date: | Fri, 18 Jul 2014 05:07:34 +0000 |
| Subject: | Bug #66091 [Com]: Memory leak in DateTime::createFromFormat() | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-186713@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=66091&edit=1
ID: 66091
Comment by: nurlan0000 at gmail dot com
Reported by: lars_teuber at gmx dot de
Summary: Memory leak in DateTime::createFromFormat()
Status: Assigned
Type: Bug
Package: Unknown/Other Function
Operating System: Windows/Linux
PHP Version: Irrelevant
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
Here's the valgrind output for test.php:
for ( $i = 0; $i < 100000; $i++ ) {
$d = DateTime::createFromFormat('m-d-Y', '05-21-2014');
unset($d);
}
valgrind --leak-check=yes --leak-check=full --show-leak-kinds=all php test.php
==21278== 5,922 bytes in 416 blocks are still reachable in loss record 14 of 18
==21278== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21278== by 0x698C679: strdup (strdup.c:42)
==21278== by 0x48BCB4: ??? (in /usr/bin/php5)
==21278== by 0x48C164: timelib_builtin_db (in /usr/bin/php5)
==21278== by 0x46D1CC: php_date_initialize (in /usr/bin/php5)
==21278== by 0x46D41D: zif_date_create_from_format (in /usr/bin/php5)
==21278== by 0x6DD6BA: dtrace_execute_internal (in /usr/bin/php5)
==21278== by 0x79D714: ??? (in /usr/bin/php5)
==21278== by 0x717447: execute_ex (in /usr/bin/php5)
==21278== by 0x6DD5B8: dtrace_execute_ex (in /usr/bin/php5)
==21278== by 0x6EF03F: zend_execute_scripts (in /usr/bin/php5)
==21278== by 0x68EF24: php_execute_script (in /usr/bin/php5)
==21278==
==21278== 8,168 bytes in 1 blocks are still reachable in loss record 15 of 18
==21278== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21278== by 0x48BB48: ??? (in /usr/bin/php5)
==21278== by 0x48C164: timelib_builtin_db (in /usr/bin/php5)
==21278== by 0x46D1CC: php_date_initialize (in /usr/bin/php5)
==21278== by 0x46D41D: zif_date_create_from_format (in /usr/bin/php5)
==21278== by 0x6DD6BA: dtrace_execute_internal (in /usr/bin/php5)
==21278== by 0x79D714: ??? (in /usr/bin/php5)
==21278== by 0x717447: execute_ex (in /usr/bin/php5)
==21278== by 0x6DD5B8: dtrace_execute_ex (in /usr/bin/php5)
==21278== by 0x6EF03F: zend_execute_scripts (in /usr/bin/php5)
==21278== by 0x68EF24: php_execute_script (in /usr/bin/php5)
==21278== by 0x79F6ED: ??? (in /usr/bin/php5)
==21278==
==21278== 9,029 bytes in 594 blocks are still reachable in loss record 16 of 18
==21278== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21278== by 0x698C679: strdup (strdup.c:42)
==21278== by 0x48B994: ??? (in /usr/bin/php5)
==21278== by 0x48C15F: timelib_builtin_db (in /usr/bin/php5)
==21278== by 0x46D1CC: php_date_initialize (in /usr/bin/php5)
==21278== by 0x46D41D: zif_date_create_from_format (in /usr/bin/php5)
==21278== by 0x6DD6BA: dtrace_execute_internal (in /usr/bin/php5)
==21278== by 0x79D714: ??? (in /usr/bin/php5)
==21278== by 0x717447: execute_ex (in /usr/bin/php5)
==21278== by 0x6DD5B8: dtrace_execute_ex (in /usr/bin/php5)
==21278== by 0x6EF03F: zend_execute_scripts (in /usr/bin/php5)
==21278== by 0x68EF24: php_execute_script (in /usr/bin/php5)
==21278==
==21278== 16,384 bytes in 1 blocks are still reachable in loss record 17 of 18
==21278== at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21278== by 0x48BA89: ??? (in /usr/bin/php5)
==21278== by 0x48C15F: timelib_builtin_db (in /usr/bin/php5)
==21278== by 0x46D1CC: php_date_initialize (in /usr/bin/php5)
==21278== by 0x46D41D: zif_date_create_from_format (in /usr/bin/php5)
==21278== by 0x6DD6BA: dtrace_execute_internal (in /usr/bin/php5)
==21278== by 0x79D714: ??? (in /usr/bin/php5)
==21278== by 0x717447: execute_ex (in /usr/bin/php5)
==21278== by 0x6DD5B8: dtrace_execute_ex (in /usr/bin/php5)
==21278== by 0x6EF03F: zend_execute_scripts (in /usr/bin/php5)
==21278== by 0x68EF24: php_execute_script (in /usr/bin/php5)
==21278== by 0x79F6ED: ??? (in /usr/bin/php5)
==21278==
==21278== 43,264 bytes in 416 blocks are still reachable in loss record 18 of 18
==21278== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21278== by 0x48BC85: ??? (in /usr/bin/php5)
==21278== by 0x48C164: timelib_builtin_db (in /usr/bin/php5)
==21278== by 0x46D1CC: php_date_initialize (in /usr/bin/php5)
==21278== by 0x46D41D: zif_date_create_from_format (in /usr/bin/php5)
==21278== by 0x6DD6BA: dtrace_execute_internal (in /usr/bin/php5)
==21278== by 0x79D714: ??? (in /usr/bin/php5)
==21278== by 0x717447: execute_ex (in /usr/bin/php5)
==21278== by 0x6DD5B8: dtrace_execute_ex (in /usr/bin/php5)
==21278== by 0x6EF03F: zend_execute_scripts (in /usr/bin/php5)
==21278== by 0x68EF24: php_execute_script (in /usr/bin/php5)
==21278== by 0x79F6ED: ??? (in /usr/bin/php5)
Previous Comments:
------------------------------------------------------------------------
[2014-07-18 04:31:32] nurlan0000 at gmail dot com
@ab, It's been almost a year since the bug was reported. Any updates on this?
------------------------------------------------------------------------
[2014-04-06 13:00:08] ab@php.net
@nikic, now looking at the code of date_load_from_format i think you're right. In case it has
to RETURN_FALSE a leak is possible. I will check that, thanks.
------------------------------------------------------------------------
[2014-04-05 19:53:08] nikic@php.net
@ab: If you don't use the return value of a function call, it will be immidiately destroyed. As
such there should be no difference between ignoring the return value and doing an assing+unset. To
me this looks like we're indeed leaking something.
------------------------------------------------------------------------
[2014-04-05 17:03:46] ab@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to
report
a bug at http://bugs.php.net/how-to-report.php
so marking as nab
------------------------------------------------------------------------
[2014-04-05 17:03:04] ab@php.net
But in your code, you just continuously create new objects. It is then logic that the memory is
cluttered up. Try using the return value and then explicitly unset() it.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=66091
--
Edit this bug report at https://bugs.php.net/bug.php?id=66091&edit=1