Re: [PHP-DEV] destructors and output_buffering

Hi,

Another possible behaviour would be to trigger a fatal when trying to 
access a partially destroyed object in ob_start.
It took me a while to actually figure out why the memory was corrupted 
when doing stuff in ob_start() (even before playing with the AMQP lib).
Having a fatal would allow me to save a lot of time, and it should not 
introduce any BC issue since any existing code accessing a partially 
destroyed object could randomly crash at some point.

   Jocelyn



Le 31/08/2014 20:48, Stas Malyshev a écrit :
> Hi!
>
>> Instead of iterating through all objects and setting a flag, can't we
>> set a global flag that object dtors are not called after this point?
> We could, but that would probably break some code that expects dtors to
> be actually called. E.g. in the bug, the library there seems to do a lot
> from the dtor, and if we just shut it down it may break the library. I
> don't think we can do this in 5.x.
>
> And I don't think we could get rid of the object flag in that case,
> since there could be cases of circular links that may still require this
> flag to avoid double calling of dtor (even not on shutdown).
>
>> This both solves the issue of new objects being created after the fact
>> and makes shutdown less expensive.
> I'm not sure expense of the shutdown is that big a deal though. Bigger
> deal is avoiding crashes on the shutdown.
> It seems to be that disabling dtors on all objects there is a bit too
> harsh - after all, for most of them it is fine, it's just those that
> linger after the OB code run _and_ have dependencies on other objects
> that create trouble. Another dtor round, for example, should resolve it,
> or just marking only those that linger as destroyed. This seems to have
> less impact that just banning dtors altogether.