On 31 Aug, 2014, at 9:33 am, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> 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? This is just a thought; could we delay the call to `zend_call_destructors` ONLY IF there’s output buffering taking place (i.e. ob_get_level() > 0)? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
