Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.107 as permitted sender)
Message-ID: <54027B6D.7060708@sugarcrm.com>
Date: Sat, 30 Aug 2014 18:33:33 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
CC: jocelyn fournier <jocelyn.fournier@gmail.com>, 
 Dmitry Stogov <dmitry@zend.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: destructors and output_buffering
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

I was looking at bug https://bugs.php.net/bug.php?id=67644 and it looks
like we have a bit of a problem with output buffering and dtors on
shutdown. Basically, right now our code looks like this:

	/* 2. Call all possible __destruct() functions */
	zend_try {
		zend_call_destructors(TSRMLS_C);
	} zend_end_try();

	/* 3. Flush all output buffers */
	zend_try {
	
// And here we go flushing output buffers

Now, since ob functions can have userland handlers, these handlers can
create new objects. And these objects will not benefit from orderly dtor
round that zend_call_destructors(TSRMLS_C) is providing - instead their
dtors will be called from zend_objects_store_free_object_storage() and
by then their environment may already be ruined and their dtors can not
run properly.

OTOH, moving __destruct after output buffers may not be good either, as
dtors may output something.

The problem seems to be resolved if I either duplicate
zend_call_destructors(TSRMLS_C); after the output buffers flushing or put
zend_objects_store_mark_destructed(&EG(objects_store) TSRMLS_CC);
there.

Of course, the second solution has the downside of not calling the dtors
of objects that were created while flushing ob buffers. The
zend_call_destructors would work but since output buffering is supposed
to be shut down by then, I wonder if it won't also have bad consequences
if these dtors do something with output buffering.

I'm leaning towards the second solution - if you create the objects so
late on shutdown stage, you shouldn't really expect them to be destroyed
normally, otherwise the cycle would never end. However, we could
consider the first option too. Any thoughts?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/