Edit report at http://bugs.php.net/bug.php?id=47285&edit=1
ID: 47285
Comment by: maarten at vivesta dot com
Reported by: danger at FreeBSD dot org
Summary: strtotime() still leaks memory
Status: Assigned
Type: Bug
Package: Date/time related
Operating System: *
PHP Version: 5.2 (SVN-2009-0-02)
Assigned To: derick
New Comment:
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...
Previous Comments:
------------------------------------------------------------------------
[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) ([email protected]) (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] [email protected]
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.
------------------------------------------------------------------------
[2009-07-23 20:26:57] scott at crisscott dot com
Reproduced on RHEL 4 (PHP built from source not RPM)
PHP 5.2.9 (cli) (built: May 1 2009 13:47:24)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Zend Debugger v5.2.14, Copyright (c) 1999-2008, by Zend
Technologies
Applying the patch from oliver at realtsp dot com slowed down the leak,
but did not stop it entirely.
------------------------------------------------------------------------
[2009-07-07 10:47:47] oliver at realtsp dot com
I can confirm that we can reproduce this bug on FreeBSD 7.2 with
php5.2.10 and that the patch provided by bloudon at townnews dot com
does stop the leak.
I had to manually apply the patch because copying out of the html rarely
works, so I have prepared a "clean" version which applies without errors
to the current FreeBSD 7.2 port of php5. Here it is:
http://www.realtsp.com/public/patch-ext_date_php_date.c
Oliver
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=47285
--
Edit this bug report at http://bugs.php.net/bug.php?id=47285&edit=1
