ID: 49700 Updated by: j...@php.net Reported By: indey...@php.net -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: Mac OS X 10.6.1 PHP Version: 5.3SVN-2009-09-28 (SVN) New Comment:
Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: ------------------------------------------------------------------------ [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
