ID: 49700
Updated by: j...@php.net
Reported By: indey...@php.net
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X 10.6.1
-PHP Version: 5.3SVN-2009-09-28 (SVN)
+PHP Version: 5.3SVN-2009-12-15
New Comment:
When you verify a bug exist with some snapshot/svn checkout, change the
version to reflect the fact. And since we use SVN now, maybe we should
start putting the revision of that tested checkout into the report as
well..? (I updated just the date now :)
Previous Comments:
------------------------------------------------------------------------
[2009-12-15 10:07:47] indey...@php.net
still see it with 5.3SVN-2009-12-15
------------------------------------------------------------------------
[2009-10-07 05:48:38] ahar...@php.net
I can reproduce this with the current PHP_5_3 and with a custom-built
vanilla 5.3.0 on OS X 10.6.1, so long as the new garbage collector is
enabled via zend.enable_gc or gc_enable(). Linux is unaffected, as is
the php 5.3.0 build provided with OS X 10.6. The build I'm using is an
x86_64 compile, as the reporter's also appears to be. Most of the leaks
appear to be in time zone handling routines.
Interestingly, I can actually get this to segfault for certain numbers
of loop iterations with the current PHP_5_3 head, but not with 5.3.0.
This works fine up to and including 9993 iterations of the loop,
segfaults between 9994-9996 iterations, and then generates the memory
leak output in the report from 9997 iterations onwards.
Relevant gdb output (using PHP_5_3):
(gdb) r /tmp/test.php 9995
Starting program: /Users/adam/Trees/php5.3-200910070430/sapi/cli/php
/tmp/test.php 9995
Reading symbols for shared libraries .+++++. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00007fff872b5c00 in strlen ()
(gdb) bt
#0 0x00007fff872b5c00 in strlen ()
#1 0x00000001000065b2 in date_object_get_properties
(object=0x7fff5fbff280) at
/Users/adam/Trees/php5.3-200910070430/ext/date/php_date.c:2101
#2 0x00000001003da593 in zobj_mark_grey (obj=0x1020dc328,
pz=0x7fff5fbff280) at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:383
#3 0x00000001003da6a9 in gc_mark_roots () at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:410
#4 0x00000001003daff1 in gc_collect_cycles () at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:628
#5 0x00000001003d9c2c in gc_zval_possible_root (zv=0x1009be148) at
/Users/adam/Trees/php5.3-200910070430/Zend/zend_gc.c:166
#6 0x000000010039f0a7 in _zval_ptr_dtor (zval_ptr=0x1007fdff8,
__zend_filename=0x1004ea278
"/Users/adam/Trees/php5.3-200910070430/main/main.c", __zend_lineno=1585)
at zend_gc.h:183
#7 0x0000000100331de8 in php_request_shutdown (dummy=0x0) at
/Users/adam/Trees/php5.3-200910070430/main/main.c:1585
#8 0x000000010049e057 in main (argc=3, argv=0x7fff5fbff820) at
/Users/adam/Trees/php5.3-200910070430/sapi/cli/php_cli.c:1371
(gdb) frame 1
#1 0x00000001000065b2 in date_object_get_properties
(object=0x7fff5fbff280) at
/Users/adam/Trees/php5.3-200910070430/ext/date/php_date.c:2101
2101 ZVAL_STRING(zv,
dateobj->time->tz_info->name, 1);
(gdb) print *dateobj->time->tz_info
$1 = {
name = 0x6 <Address 0x6 out of bounds>,
ttisgmtcnt = 6,
ttisstdcnt = 0,
leapcnt = 12,
timecnt = 18,
typecnt = 4,
charcnt = 4,
trans = 0x0,
trans_idx = 0x0,
type = 0x0,
timezone_abbr = 0x0,
leap_times = 0x0,
bc = 1 '\001',
location = {
country_code = "AU",
latitude = -31.950000000000003,
longitude = 115.85000000000002,
comments = 0x0
}
}
The value of dateobj->time->tz_info->name is not consistent between
runs, even with the same number of iterations, but it's always an
invalid pointer value between 0 and 15, inclusive.
For completeness, the test script I'm using:
<?php
gc_enable();
$a = array();
foreach (range(1, $_SERVER['argv'][1]) as $i) {
$a[] = new DateTime;
}
?>
And the entire contents of the php.ini being used:
date.timezone = Australia/Perth
Let me know if there's anything I can do to help debug.
tl;dr: OS X specific; only occurs with the new garbage collector
enabled; possibly related to or at least triggered by something in the
time zone code.
------------------------------------------------------------------------
[2009-10-02 22:44:55] f...@php.net
Probably Mac OS only...
Couldn't reproduce with latest snap (php5.3-200910022030) on Linux x86
without running into a memory_limit of 512 MB with CLI
------------------------------------------------------------------------
[2009-09-28 17:25:28] indey...@php.net
Description:
------------
If garbage-collector is enabled and large quantity of DateTime objects
is created, php reports memory leaks
Reproduce code:
---------------
<?php
gc_enable();
$objs = array();
foreach (range(1,20000) as $i) {
$objs[$i] = new DateTime();
}
Expected result:
----------------
DONE
Actual result:
--------------
DONE
[Mon Sep 28 21:23:24 2009] Script: '_mem_test.php'
/Users/indy/Documents/Sources/_mine/php5/ext/date/php_date.c(1137) :
Freeing 0x106340068 (79 bytes), script=_mem_test.php
Last leak repeated 39993 times
[Mon Sep 28 21:23:24 2009] Script: '_mem_test.php'
/Users/indy/Documents/Sources/_mine/php5/ext/date/php_date.c(2088) :
Freeing 0x106340118 (32 bytes), script=_mem_test.php
Last leak repeated 39993 times
[Mon Sep 28 21:23:24 2009] Script: '_mem_test.php'
/Users/indy/Documents/Sources/_mine/php5/ext/date/php_date.c(2091) :
Freeing 0x106340198 (14 bytes), script=_mem_test.php
Last leak repeated 39993 times
[Mon Sep 28 21:23:24 2009] Script: '_mem_test.php'
/Users/indy/Documents/Sources/_mine/php5/ext/date/php_date.c(2078) :
Freeing 0x106340208 (32 bytes), script=_mem_test.php
Last leak repeated 39993 times
[Mon Sep 28 21:23:24 2009] Script: '_mem_test.php'
/Users/indy/Documents/Sources/_mine/php5/ext/date/php_date.c(2084) :
Freeing 0x106340338 (32 bytes), script=_mem_test.php
Last leak repeated 39993 times
=== Total 199970 memory leaks detected ===
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=49700&edit=1
