And the last one, the most questionable patch.
ATM ZE2 calls destructor at the end of the request and no matter
is there were a fatal error (which should probably stop executing the script).
In some cases it leads to nasty segfaults (me and report's author can reproduce
it, but others can't. weird..).
Some persons (hello, Andrey =)) think that this could be a useful feature, but
for me it's just an inconsistency. IMO destructors should not be called after
fatal errors, because they can cause even more harm.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
I think this makes sense because PHP could be in an unstable state. Think
EG(exit_status) covers all possible situations? No time to check now how it
differs from CG(unclean_shutdown) which is most often used.
Andi
At 09:57 AM 9/10/2004 +0400, Antony Dovgal wrote:
And the last one, the most questionable patch.
ATM ZE2 calls destructor at the end of the request and no matter
is there were a fatal error (which should probably stop executing the script).
In some cases it leads to nasty segfaults (me and report's author can
reproduce
it, but others can't. weird..).Some persons (hello, Andrey =)) think that this could be a useful feature,
but
for me it's just an inconsistency. IMO destructors should not be called after
fatal errors, because they can cause even more harm.--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
On Thu, 09 Sep 2004 23:15:08 -0700
Andi Gutmans andi@zend.com wrote:
I think this makes sense because PHP could be in an unstable state.
Think EG(exit_status) covers all possible situations? No time to check
now how it differs from CG(unclean_shutdown) which is most often used.
Well, as I can see zend_error() doesn't change CG(unclean_shutdown), but uses EG(exit_status) instead.
And there is a side-effect: using exit_status we allow user to disable destructors calling exit($non_zero_status);
Probably, this patch needs some more investigation.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
- Thus wrote Antony Dovgal:
And the last one, the most questionable patch.
ATM ZE2 calls destructor at the end of the request and no matter
is there were a fatal error (which should probably stop executing
the script). In some cases it leads to nasty segfaults (me and
report's author can reproduce it, but others can't. weird..).
I'm not sure if this has anything to do with it but the destructor
is being called before the constructor actually finishes, I would
think the state of the object itself isn't stable. I can stop the
segfault happening if I cause the fatal error after the object is
created.
Some persons (hello, Andrey =)) think that this could be a useful
feature, but for me it's just an inconsistency. IMO destructors
should not be called after fatal errors, because they can cause
even more harm.
Might want to add me to that list :) A use I can see is if the
object manages a buffer of some sort and the destructor ensures
that it is flushed, a bypass of the destructor would cause the
buffer to get lost.
Curt
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about. No, sir. Our model is the trapezoid!
On Fri, 10 Sep 2004 16:23:41 +0000
Curt Zirzow curt@php.net wrote:
Might want to add me to that list :) A use I can see is if the
object manages a buffer of some sort and the destructor ensures
that it is flushed, a bypass of the destructor would cause the
buffer to get lost.
Yup. Because it was a FATAL error.
http://www.php.net/manual/en/ref.errorfunc.php#e-error
E_ERROR (integer) - Fatal run-time errors. These indicate errors that can
not be recovered from, such as a memory allocation problem.
Execution of the script is halted.
I'm not a person to make this decision, but I think that fatal error should
really halt execution as the documentation says.
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
Curt Zirzow wrote:
- Thus wrote Antony Dovgal:
And the last one, the most questionable patch.
ATM ZE2 calls destructor at the end of the request and no matter
is there were a fatal error (which should probably stop executing
the script). In some cases it leads to nasty segfaults (me and
report's author can reproduce it, but others can't. weird..).I'm not sure if this has anything to do with it but the destructor
is being called before the constructor actually finishes, I would
think the state of the object itself isn't stable. I can stop the
segfault happening if I cause the fatal error after the object is
created.Some persons (hello, Andrey =)) think that this could be a useful
feature, but for me it's just an inconsistency. IMO destructors
should not be called after fatal errors, because they can cause
even more harm.Might want to add me to that list :) A use I can see is if the
object manages a buffer of some sort and the destructor ensures
that it is flushed, a bypass of the destructor would cause the
buffer to get lost.
Well, the system is in unstable state and that means that a flush
may fail but a try is better than nothing.
Andrey
AD>>ATM ZE2 calls destructor at the end of the request and no matter is
AD>>there were a fatal error (which should probably stop executing the
AD>>script). In some cases it leads to nasty segfaults (me and report's
AD>>author can reproduce it, but others can't. weird..).
Well, the cause of the faults is as follows:
If we are in shutdown, and one of the destructors fails with fatal error,
then other destructors for other objects are not called. Thus, their
if they hold some objects, destructors for these objects will not be
called. Later, when the storage is cleaned with
zend_objects_store_free_object_storage(), engine will attempt to call
dtors for objects that didn't have their dtors called before. However, on
that stage engine is already unable to run PHP code (function and class
tables are already cleaned, etc.) - so it crashes.
What I would propose is to inhibit calling destructors after
shutdown_destructors() was finished.
--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
On Mon, 13 Sep 2004 14:02:43 +0300 (IDT)
Stanislav Malyshev stas@zend.com wrote:
AD>>ATM ZE2 calls destructor at the end of the request and no matter
AD>is>there were a fatal error (which should probably stop executing
AD>the>script). In some cases it leads to nasty segfaults (me and
AD>report's>author can reproduce it, but others can't. weird..).Well, the cause of the faults is as follows:
If we are in shutdown, and one of the destructors fails with fatal
error, then other destructors for other objects are not called. Thus,
their if they hold some objects, destructors for these objects will
not be called. Later, when the storage is cleaned with
zend_objects_store_free_object_storage(), engine will attempt to call
dtors for objects that didn't have their dtors called before. However,
on that stage engine is already unable to run PHP code (function and
class tables are already cleaned, etc.) - so it crashes.
Looks like you're right, but why others can't reproduce this segfault?
What I would propose is to inhibit calling destructors after
shutdown_destructors() was finished.
Sounds nice: we should not call destructors after they were already called =)
I could propose a simple solution: add a global flag, which will indicate
that shutdown_destructors() was called, and do appropriate check in
zend_objects_store_del_ref().
Comments/objections?
--
Wbr,
Antony Dovgal aka tony2001
tony2001@phpclub.net || antony@dovgal.com
Hello Antony,
Maybe this was assumed, but wouldn't this be a per-request flag,
rather than a global flag?
--
Best regards,
Jason mailto:jason@ionzoft.com
Tuesday, September 14, 2004, 10:18:29 AM, you wrote:
AD> Sounds nice: we should not call destructors after they were already called =)
AD> I could propose a simple solution: add a global flag, which will indicate
AD> that shutdown_destructors() was called, and do appropriate check in
AD> zend_objects_store_del_ref().
AD> Comments/objections?
At 02:02 PM 9/13/2004 +0300, Stanislav Malyshev wrote:
AD>>ATM ZE2 calls destructor at the end of the request and no matter is
AD>>there were a fatal error (which should probably stop executing the
AD>>script). In some cases it leads to nasty segfaults (me and report's
AD>>author can reproduce it, but others can't. weird..).Well, the cause of the faults is as follows:
If we are in shutdown, and one of the destructors fails with fatal error,
then other destructors for other objects are not called. Thus, their
if they hold some objects, destructors for these objects will not be
called. Later, when the storage is cleaned with
zend_objects_store_free_object_storage(), engine will attempt to call
dtors for objects that didn't have their dtors called before. However, on
that stage engine is already unable to run PHP code (function and class
tables are already cleaned, etc.) - so it crashes.What I would propose is to inhibit calling destructors after
shutdown_destructors() was finished.--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115
Yes I agree.
At 02:02 PM 9/13/2004 +0300, Stanislav Malyshev wrote:
AD>>ATM ZE2 calls destructor at the end of the request and no matter is
AD>>there were a fatal error (which should probably stop executing the
AD>>script). In some cases it leads to nasty segfaults (me and report's
AD>>author can reproduce it, but others can't. weird..).Well, the cause of the faults is as follows:
If we are in shutdown, and one of the destructors fails with fatal error,
then other destructors for other objects are not called. Thus, their
if they hold some objects, destructors for these objects will not be
called. Later, when the storage is cleaned with
zend_objects_store_free_object_storage(), engine will attempt to call
dtors for objects that didn't have their dtors called before. However, on
that stage engine is already unable to run PHP code (function and class
tables are already cleaned, etc.) - so it crashes.What I would propose is to inhibit calling destructors after
shutdown_destructors() was finished.--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115