php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #53803 circular reference between SPL classes not collected by gc_collect_cycles()
Submitted: 2011-01-21 13:09 UTC Modified: 2015-08-27 21:38 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: oliver at openbrackets dot net Assigned: nikic (profile)
Status: Closed Package: SPL related
PHP Version: 5.3.5 OS: FreeBSD
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: oliver at openbrackets dot net
New email:
PHP Version: OS:

 

 [2011-01-21 13:09 UTC] oliver at openbrackets dot net
Description:
------------
Circular references between instances of SPL classes are not "cleaned up" by gc_collect_cycles().

The code in the test script can be run from cli. It shows growing memory usage because the circular references between the instances of an extended ArrayObject class and instances of ArrayIterator are not cleaned up by gc_collect_cycles.

The long code sample, downloadable from the url provided in "test script section" shows:

Case1: SPL classes: expecting gc_collect_cycles to clean up circ references
Case2: SPL classes: manual clearing of the circular reference
Case3: Userland classes: expecting gc_collect_cycles to clean up circ references

This looks similar to http://bugs.php.net/53071 , BUT I am running php5.3.5 which AFAIK includes r304723 and r304724 which were supposed to fix #53071.




Test script:
---------------
Short code sample:

class Collection extends ArrayObject implements Serializable
{
  protected $iterator;

  public function getIterator()
  {
    $this->iterator = new ArrayIterator($this);
    return $this->iterator;
  }

  public function clearIterator()
  {
    $this->iterator = null;
  }
}

echo "Case 1: ArrayObject/ArrayIterator: expecting gc_collect_cycles() to clean up...\n";

for ($i = 1; $i <= 100; $i++)
{
  $books = array('war and peace', 'crime and punishment');
  $book_collection = new Collection($books);
  $iterator = $book_collection->getIterator();

  echo gc_collect_cycles() . ":" . memory_get_peak_usage() . "\n";
}


full code sample:

http://www.realtsp.com/download/php_circular_reference_test_code_sample.txt


Expected result:
----------------
Expect all test cases (Case1, Case2, Case3) to have constant peak memory usage. 



Actual result:
--------------
Only Case2 and Case3 have constant memory usage.

In Case1 memory usage grows linearly with loops iterations. 

This shows that gc_collect_cycles is not collecting circular references between SPL classes. Also shown because it returns "0 cycles collected". In Case 3 (Userland classes) gc_collect_cycles shows "5 cycles collected" each iteration.





Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-01-27 16:12 UTC] cataphract@php.net
The fix for bug #53071 never claimed to fix all circular reference problems in SPL classes, it fixed only the behavior in SPLObjectStorage.

In fact, the problem is a design one and it is caused by the inability of the garbage collector to know an object holds a reference to a certain variable except through a property contained in the hash table returned by the get_properties handler.

The "fix" to bug #53071 is actually a quite a hack; a proper solution would involve maybe adding an extra object handler for the garbage collector to use, but that cannot be done in the 5.3 branch. I'm not entirely convinced fixing ArrayObject (which seems to be what this bug is about) is as compelling as fixing SPLObjectStorage, which usually acts as a container for many objects and therefore where inhibiting garbage collection is more problematic.
 [2011-01-28 10:20 UTC] oliver at openbrackets dot net
ok, that makes sense. 

By saying: 
"I'm not
entirely convinced fixing ArrayObject (which seems to be what this bug
is about) is as compelling as fixing SPLObjectStorage, which usually
acts as a container for many objects and therefore where inhibiting
garbage collection is more problematic."

Are you suggesting that it would be possible to rewrite the test Case1 using SplObjectStorage? Or that we have to live with GC not being able to clean up these circular references for th time being?
 [2011-02-02 02:30 UTC] cataphract@php.net
I don't see how using SplObjectStorage would help, as it's a completely different class. I'm saying for the time being you should destroy the cycles manually instead of relying on the GC.

In any case, I'm not marking this Wont Fix.
 [2015-08-27 21:38 UTC] nikic@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: nikic
 [2015-08-27 21:38 UTC] nikic@php.net
This is fixed in PHP 7 by https://github.com/php/php-src/commit/4e03ba4a6ef4c16b53e49e32eb4992a797ae08a8 (and a number of preceding commits).
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 08:01:32 2024 UTC