Hi!
On Tue, Sep 2, 2014 at 12:56 AM, Stas Malyshev
wrote:
> Hi!
>
> I've created a proposed fix for #67644:
>
> https://github.com/php/php-src/pull/798
Looks like this fix breaks some tests, so I'm not feeling good putting it
into 5.4. I'll revert it for now and try to figure out a better sol
Hi Stas,
Actually I would love flushing ob_start() in my own shutdown function,
but since my application is a library called in auto_prepend_file, I
have to protect ob_start() from being flushed too early by some wrong
code in the client application.
Hence I'm removing the PHP_OUTPUT_HANDLER_C
Hi!
> One line fix, nice :)
>
> A quick question about how resources are freed :
> if some variables are computed inside a singleton and read through a
> myclass::instance()->get_my_variable(), should we expect to have those
> variables available when calling ob_start() callbacks ?
>
> From e
Hi,
One line fix, nice :)
A quick question about how resources are freed :
if some variables are computed inside a singleton and read through a
myclass::instance()->get_my_variable(), should we expect to have those
variables available when calling ob_start() callbacks ?
From experiment, they
Hi!
I've created a proposed fix for #67644:
https://github.com/php/php-src/pull/798
It is the most conservative one which I'm thinking of putting into 5.4,
so that at least we won't have segfaults. If we want to improve upon it,
we can do that in 5.5/5.6, but I'd like at least plug the segfaults
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
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
On Sun, Aug 31, 2014 at 3:33 AM, Stas Malyshev
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 possib
On 31 Aug, 2014, at 12:40 pm, Stas Malyshev wrote:
> Hi!
>
>> 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)?
>
> That wouldn't help - imagine this:
> 1. ob_start is set
> 2. shutdown is s
Hi!
> 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)?
That wouldn't help - imagine this:
1. ob_start is set
2. shutdown is starting
3. ob functions shut down, call function foo
4. function foo
On 31 Aug, 2014, at 9:33 am, Stas Malyshev 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
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
12 matches
Mail list logo
