Edit report at http://bugs.php.net/bug.php?id=49700&edit=1
ID: 49700 Updated by: [email protected] Reported by: [email protected] Summary: memory leaks in php_date.c if garbage collector is enabled Status: Assigned Type: Bug Package: Date/time related Operating System: Mac OS X 10.6.1 PHP Version: 5.3SVN-2009-12-15 -Assigned To: derick +Assigned To: dmitry New Comment: This is odd, I've no idea why this should be needed. Dmitry, can you clarify why this is perhaps? Previous Comments: ------------------------------------------------------------------------ [2010-03-05 11:22:24] [email protected] The following patch has been added/updated: Patch Name: datetime-gc-issue Revision: 1267784544 URL: http://bugs.php.net/patch-display.php?bug=49700&patch=datetime-gc-issue&revision=1267784544&display=1 ------------------------------------------------------------------------ [2009-12-15 20:02:00] [email protected] 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 :) ------------------------------------------------------------------------ [2009-12-15 10:07:47] [email protected] still see it with 5.3SVN-2009-12-15 ------------------------------------------------------------------------ [2009-10-07 05:48:38] [email protected] 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] [email protected] 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 ------------------------------------------------------------------------ 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=49700 -- Edit this bug report at http://bugs.php.net/bug.php?id=49700&edit=1
