|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2015-05-05 03:12 UTC] laruence@php.net
-Assigned To:
+Assigned To: dmitry
[2015-05-05 23:11 UTC] dmitry@php.net
[2015-05-06 18:34 UTC] dmitry@php.net
[2015-05-06 18:34 UTC] dmitry@php.net
-Status: Assigned
+Status: Closed
[2016-07-20 11:38 UTC] davey@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Mon Oct 27 07:00:01 2025 UTC |
Description: ------------ This code... <?php class Node extends SplObjectStorage { public $prop; } $node1 = new Node; $node2 = new Node; $node1->prop = $node2; $node2->prop = $node1; ...will leaks the Node#1, Node#2 cycle. "SplObjectStorage" can be replaced with any internal class that implements a custom get_gc handler and uses the usual "custom data table + return std properties" pattern. The reason is that the GC code no longer checks for INDIRECT elements in the properties hash and assumes that these elements will also be present in the data table. This is usually not true for internal objects. Possible resolutions: a) Handle INDIRECT in the GC again. b) Require that the table populated by GC always contains the std properties table. This would prevent directly returning pointers to internal tables for classes like SplFixedArray, SplHeap or ArrayObject/Iterator and instead require maintaining gc_data/gc_data_num members like we already do in some other places. In this variant the default get_gc handler should also be changed to ignore custom get_properties handlers.