Edit report at https://bugs.php.net/bug.php?id=47285&edit=1
ID: 47285
Updated by: cmb@php.net
Reported by: danger at FreeBSD dot org
Summary: strtotime() still leaks memory
-Status: Assigned
+Status: Closed
Type: Bug
Package: Date/time related
Operating System: *
PHP Version: 5.2 (SVN-2009-0-02)
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
I've just ran maartens valgrind repro on most recent PHP 5.6 and
master on Debian Jessie:
All heap blocks were freed -- no leaks are possible
Furthermore I've ran the OP's test script on Windows 7 with most
recent PHP 5.6 and master, and I can't detect any memory leaks.
So apparently this issue has been resolved â closing.
Previous Comments:
------------------------------------------------------------------------
[2015-04-05 20:43:39] kalle@php.net
Based on the comment from Jani, is this finally fixed?
------------------------------------------------------------------------
[2010-03-11 15:25:21] maarten at vivesta dot com
I've built PHP 5.2 from SVN (r.296066) from scratch on vanilla Debian Lenny and
ran valgrind on this problem. Here is the output:
$ valgrind --leak-check=full ./sapi/cli/php -n -r 'strtotime("now",time());'
==21329== Memcheck, a memory error detector.
==21329== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==21329== Using LibVEX rev 1854, a library for dynamic binary translation.
==21329== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==21329== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==21329== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==21329== For more details, rerun with: -v
==21329==
==21329==
==21329== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 27 from 1)
==21329== malloc/free: in use at exit: 76 bytes in 4 blocks.
==21329== malloc/free: 7,796 allocs, 7,792 frees, 1,305,337 bytes allocated.
==21329== For counts of detected errors, rerun with: -v
==21329== searching for pointers to 4 not-freed blocks.
==21329== checked 429,556 bytes.
==21329==
==21329== 76 (48 direct, 28 indirect) bytes in 1 blocks are definitely lost in
loss record 4 of 4
==21329== at 0x4021E22: calloc (vg_replace_malloc.c:397)
==21329== by 0x809DDAA: timelib_tzinfo_ctor (timelib.c:75)
==21329== by 0x809D0F7: timelib_parse_tzfile (parse_tz.c:277)
==21329== by 0x8084211: timelib_get_zone (parse_date.re:737)
==21329== by 0x8085859: timelib_strtotime (parse_date.re:1007)
==21329== by 0x8080A4C: zif_strtotime (php_date.c:1143)
==21329== by 0x8284379: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:200)
==21329== by 0x82710AF: execute (zend_vm_execute.h:92)
==21329== by 0x8243A26: zend_eval_string (zend_execute_API.c:1223)
==21329== by 0x8243B7E: zend_eval_string_ex (zend_execute_API.c:1258)
==21329== by 0x82BCC29: main (php_cli.c:1204)
==21329==
==21329== LEAK SUMMARY:
==21329== definitely lost: 48 bytes in 1 blocks.
==21329== indirectly lost: 28 bytes in 3 blocks.
==21329== possibly lost: 0 bytes in 0 blocks.
==21329== still reachable: 0 bytes in 0 blocks.
==21329== suppressed: 0 bytes in 0 blocks.
Please let me know if there is any more I can do, next to fixing the bug
obviously... :-) I'm looking in to that...
------------------------------------------------------------------------
[2009-09-10 01:15:08] sadrak at sogetthis dot com
Problem verified on:
Linux version 2.6.30-1-amd64 (Debian 2.6.30-6) (waldi@debian.org) (gcc version 4.3.4 (Debian
4.3.4-1) ) #1 SMP Sat Aug 15 21:08:31 UTC 2009
Using:
PHP 5.2.10-2 with Suhosin-Patch 0.9.7 (cli) (built: Jul 10 2009 00:34:06)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Suhosin v0.9.28, Copyright (c) 2007, by SektionEins GmbH
------------------------------------------------------------------------
[2009-09-02 11:52:12] jani@php.net
Reproduced on 32/64 bit servers using latest PHP_5_2 checkout. Does NOT happen with PHP_5_3.
------------------------------------------------------------------------
[2009-08-26 16:42:29] heron at xnapid dot com
I can confirm the same leak, running in Apache on Windows. Apache kills the script after a time
limit, but the leaked memory remains leaked; refreshing the same URL causes the total leaked memory
to increase from there. It looks like it leaks 800KB per second or so, and the script is killed
after leaking about 30MB.
I'm running PHP 5.2.9-2, which came straight from the default Windows installer.
------------------------------------------------------------------------
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=47285
--
Edit this bug report at https://bugs.php.net/bug.php?id=47285&edit=1