memory leaks in php_date.c if garbage collector is enabled
| Bug #49700 | memory leaks in php_date.c if garbage collector is enabled | ||||
|---|---|---|---|---|---|
| Submitted: | 2009-09-28 17:25 UTC | Modified: | 2010-04-20 17:42 UTC | ||
| From: | indeyets@php.net | Assigned: | dmitry (profile) | ||
| Status: | Closed | Package: | Date/time related | ||
| PHP Version: | 5.3SVN-2009-12-15 | OS: | Mac OS X 10.6.1 | ||
| Private report: | No | CVE-ID: | None | ||
[2009-09-28 17:25 UTC] indeyets@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 ===
Patches
datetime-gc-issue (last revision 2010-03-05 10:22 UTC by felipe@php.net)Pull Requests
History
AllCommentsChangesGit/SVN commits
[2009-10-02 22:44 UTC] fa@php.net
[2009-10-07 05:48 UTC] aharvey@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-12-15 20:02 UTC] jani@php.net
[2010-03-05 12:09 UTC] felipe@php.net
-Status: Verified +Status: Assigned
[2010-03-07 20:24 UTC] derick@php.net
-Assigned To: derick +Assigned To: dmitry
[2010-03-07 20:24 UTC] derick@php.net
[2010-04-20 17:42 UTC] dmitry@php.net
-Status: Assigned +Status: Closed
[2010-04-20 17:42 UTC] dmitry@php.net