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

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.

still see it with 5.3SVN-2009-12-15

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 :)

This is odd, I've no idea why this should be needed. Dmitry, can you clarify why this is perhaps?

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.