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
I use a lot of unserialized objects and realised that destructors do
not get called implicitly for them. Is this the intended behavior ?
Precisions on this would be greatly appreciated, thank you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Hello Noel,
my code snippet only illustrates that an exception without a stackframe is
an exception not thrown during normal script execution. E.g. this happens
when code is executed during shutdown. This can normally only happen drom
other destructors or from some global error handling.
regards
Hey Marcus,
Although your script did work, it appears that the exception doesn't
even need to be thrown in the destructor of a class, but rather anywhere
as long as there is a destructor in any instantiated class. Here's a
code snippet:
public function create($host, $port, $protocol = 'tcp'
Hello Noel,
i suppose one of your destructors did throw an exception. But you didn't
get any output from it. Try either 5.0.0-dev or 5.1.0-dev where the
shutdown order wasaddressed again. A reproducing script would be this:
php -r 'class t{function __destruct(){throw new exception(__METHOD__);}}$
Hello all,
You'll have to excuse my ignorance if something like this has already
been posted.
In my process of writing complicated-for-the-sake-of-complicated scripts
(:D), I came across a very strange error:
Fatal error: Exception thrown without a stack frame in Unknown on line 0
What was happ
Hello,
This is a question relating to the new PHP5 Object Destructor
functionality. Consider the following:
class DB
{
function Query() { ... }
}
class Session
{
function SetVar() {
//sets a variable to be saved in the session
}
function __destruct() {
//Save session var
Hello Internals,
I´m writing some material about PHP5 and I have
some doubts about destructors. If someone would like
to help me, it can be done in off.
It´s basically how is the order that shutdown
occurs in PHP5:
- When exactaly __destruct() is called?
- What resources still availa
19 matches
Mail list logo
