|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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: 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]
If garbage-collector is enabled and large quantity of DateTime objects is created, php reports memory leaks

Reproduce code:


$objs = array();
foreach (range(1,20000) as $i) {
    $objs[$i] = new DateTime();

Expected result:

Actual result:
[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 ===


datetime-gc-issue (last revision 2010-03-05 10:22 UTC) by

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-02 22:44 UTC]
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-10-07 05:48 UTC]
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:


$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 10:07 UTC]
still see it with 5.3SVN-2009-12-15
 [2009-12-15 20:02 UTC]
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 :)
 [2010-03-05 11:22 UTC]
The following patch has been added/updated:

Patch Name: datetime-gc-issue
Revision:   1267784544
 [2010-03-05 12:09 UTC]
-Status: Verified +Status: Assigned
 [2010-03-07 20:24 UTC]
-Assigned To: derick +Assigned To: dmitry
 [2010-03-07 20:24 UTC]
This is odd, I've no idea why this should be needed. Dmitry, can you clarify why this is perhaps?
 [2010-04-20 17:41 UTC]
Automatic comment from SVN on behalf of dmitry
Log: Fixed bug #49700 (memory leaks in php_date.c if garbage collector is enabled)
 [2010-04-20 17:42 UTC]
-Status: Assigned +Status: Closed
 [2010-04-20 17:42 UTC]
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
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC