#47285 [Com]: strtotime() still leaks memory

2009-02-13 Thread maarten at vivesta dot com
 ID:   47285
 Comment by:   maarten at vivesta dot com
 Reported By:  danger at FreeBSD dot org
 Status:   No Feedback
 Bug Type: Date/time related
 Operating System: FreeBSD
 PHP Version:  5.2.8
 New Comment:

I have the same problem:

PHP 5.2.9RC2-dev (cli) (built: Feb 12 2009 15:10:25)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

On FreeBSD 6.3. Built PHP without FreeBSD patches, just downloaded 
latest and did "cd php5.2-200902121330", "./configure", "make" and 
"./sapi/cli/php"

http://cvsweb.freebsd.org/ports/lang/php5/files.

Verified that the above PHP version still leaks memory, slower but
still.



[2009-02-03 22:15:18] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





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/47285

-- 
Edit this bug report at http://bugs.php.net/?id=47285&edit=1



#47285 [Com]: strtotime() still leaks memory

2009-02-17 Thread maarten at vivesta dot com
 ID:   47285
 Comment by:   maarten at vivesta dot com
 Reported By:  danger at FreeBSD dot org
 Status:   Feedback
 Bug Type: Date/time related
 Operating System: FreeBSD
 PHP Version:  5.2.8
 Assigned To:  derick
 New Comment:

Ok, I've sent you login details to a testmachine by e-mail.


Previous Comments:


[2009-02-15 12:54:34] der...@php.net

Please send me account details (by email), as I still can't reproduce
this.



[2009-02-13 11:02:06] maarten at vivesta dot com

I have the same problem:

PHP 5.2.9RC2-dev (cli) (built: Feb 12 2009 15:10:25)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

On FreeBSD 6.3. Built PHP without FreeBSD patches, just downloaded 
latest and did "cd php5.2-200902121330", "./configure", "make" and 
"./sapi/cli/php"

http://cvsweb.freebsd.org/ports/lang/php5/files.

Verified that the above PHP version still leaks memory, slower but
still.



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/47285

-- 
Edit this bug report at http://bugs.php.net/?id=47285&edit=1



#47285 [Com]: strtotime() still leaks memory

2009-02-27 Thread maarten at vivesta dot com
 ID:   47285
 Comment by:   maarten at vivesta dot com
 Reported By:  danger at FreeBSD dot org
 Status:   Assigned
 Bug Type: Date/time related
 Operating System: FreeBSD
 PHP Version:  5.2.8
 Assigned To:  derick
 New Comment:

Same here. I've added a date_default_timezone_set() before using 
strtotime() and it removed the error but not the leak.


Previous Comments:


[2009-02-27 13:53:29] danger at FreeBSD dot org

I tried to run my script with php -d error_reporting=E_STRICT test.php
and been receiving this error until I stopped the script:

Strict Standards: strtotime(): It is not safe to rely on the system's
timezone settings. Please use the date.timezone setting, the TZ
environment variable or the date_default_timezone_set() function. In
case you used any of those methods and you are still getting this
warning, you most likely misspelled the timezone identifier. We selected
'Europe/Berlin' for 'CET/1.0/no DST' instead in /root/test.php on line
10



[2009-02-27 13:25:37] danger at FreeBSD dot org

Hey there,

I have tried to build a stock php-5.2.9 (no FreeBSD patches or anything
else) with ./configure && make. 

When I run my test script as this:
r...@[temp /var/ports/distfiles/php-5.2.9]# sapi/cli/php
/root/test.php

No modified php.ini is being used, no additional extensions are being
loaded. I can still verify that it leaks.



[2009-02-27 11:44:35] der...@php.net

I am not forgetting about this, but at the moment just really occupied.
Just as a quick question, this is the *stock* PHP without any ports
patches, also, if you set the error level to also show e_Strict
messages, do you see anything? Also, do you have the date.timezone
setting made in PHP.ini?



[2009-02-27 10:41:02] danger at FreeBSD dot org

verified to still leak with:

r...@[temp /basejail/usr/ports/lang/php5]# php -v
PHP 5.2.9 (cli) (built: Feb 27 2009 11:36:57)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies



[2009-02-23 08:59:23] danger at FreeBSD dot org

Any news on this? I checked the box and it seems like you logged only
once for a few seconds almost a week ago



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/47285

-- 
Edit this bug report at http://bugs.php.net/?id=47285&edit=1



Bug #47285 [Com]: strtotime() still leaks memory

2010-03-11 Thread maarten at vivesta dot com
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) (wa...@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] j...@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.


[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" vers