Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51733
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain wikimedia.org from 66.111.4.27 cause and error)
Message-ID: <4D8699DC.2060801@wikimedia.org>
Date: Mon, 21 Mar 2011 11:20:44 +1100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: internals Mailing List <internals@lists.php.net>
References: <4D803F21.1010209@wikimedia.org> <4D855DF2.8040702@wikimedia.org> <4D8574EF.60003@sugarcrm.com>
In-Reply-To: <4D8574EF.60003@sugarcrm.com>
OpenPGP: id=BF976370
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [patch] Session RSHUTDOWN, shutdown_destructors() issues
From: tstarling@wikimedia.org (Tim Starling)

On 20/03/11 14:30, Stas Malyshev wrote:
> Hi!
>
>> I guess I'm suffering from some tl;dr here. Here's the short version:
>> please apply the attached patch to the 5.3 branch. It removes some
>> code which is broken and unnecessary.
>
> I'm not sure it's a good idea. That code is there for a reason,
> specifically: http://svn.php.net/viewvc?view=revision&revision=216213
> Did you check that this test still works when you apply your patch?

It doesn't work, because my patch is just a revert.

That bug (36759) doesn't seem to have anything to do with global
variables, so deleting global variables seems like an odd response to it.

r216213 fixes that one test case, but it seems like the actual
complaint there is that objects stored in member variables are
destroyed before their parent objects. r216213 fixes this by assuming
that all parent objects will be in the global symbol table. It deletes
global symbol table entries, so that only objects which are referred
to from somewhere else will survive until the
zend_objects_store_call_destructors().

If you take Dmitry's test case and replace this:

$y = new Bar();
$x = new Foo($y);

with this:

function foo() {
    static $x, $y;
    $y = new Bar();
    $x = new Foo($y);
}
foo();

then the bug is still seen. Or indeed, because of the logic error I've
discussed, this also shows an incorrect destructor order:

$y = new Bar();
$x = new Foo($y);
$z = $x;

Can you reopen bug 36759 please?

-- Tim Starling