Bug #66091 [Com]: Memory leak in DateTime::createFromFormat()

From: Date: Fri, 18 Jul 2014 05:25:41 +0000
Subject: Bug #66091 [Com]: Memory leak in DateTime::createFromFormat()
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-186714@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: I think I've found situation when the memory leak occurs. Memory is leaked only when you try to parse invalid date. Here's example script: for ( $i = 0; $i < 10000; $i++ ) { $d = DateTime::createFromFormat('m-d-Y', 'asdf asdf'); unset($d); if ($i % 100 == 0) { echo 'Memory usage: ', memory_get_usage(), PHP_EOL; } } Previous Comments: ------------------------------------------------------------------------ [2014-07-18 05:07:33] nurlan0000 at gmail dot com 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) ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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

« previous php.bugs (#186714) next »