* PHP-5.5:
update NEWS
Only destruct if EG(active) in zend_shutdown(). (bug #65463, #66036)
Fix typo from commit 32314f6b6
Fix destruction order in zend_shutdown (bug #65463, #66036)
* PHP-5.4:
update NEWS
Only destruct if EG(active) in zend_shutdown(). (bug #65463, #66036)
Fix typo from commit 32314f6b6
Fix destruction order in zend_shutdown (bug #65463, #66036)
* pull-request/770:
Only destruct if EG(active) in zend_shutdown(). (bug #65463, #66036)
Fix typo from commit 32314f6b6
Fix destruction order in zend_shutdown (bug #65463, #66036)
If Apache or a similar SAPI receives a signal during PHP processing
it calls zend_shutdown() without calling shutdown_executor().
#65463: If a module like Gearman or Memcached is loaded,
in the unfixed version it is unloaded by zend_destroy_modules() before the
CG(CLASS_TABLE) is destructed. When CG(CLASS_TABLE) is destructed,
any pointers to methods (specifically around destruction) in the unloaded
module's .so are now dangling and the process segfaults.
#66036: Any subclasses of an internal class like ArrayObject need
to be destructed in order: subclass first and then the internal class. In the
unfixed version zend_shutdown() clears the CG(CLASS_TABLE) from the head
of the list onwards, so internal classes are destructed first and user-defined
classes last. Internal classes are alloc/deallocated with malloc/free while
user-defined classes with emalloc/efree. If there's shared data between them
then efree() could be called instead of free() leading to a seg-fault.
This piece of code seems to retain compatibility with some windows
versions before 2000. Today it's not relevant anymore and only
produces a warning C4273 because of the conflicting prototype. In
VC9 the declaration is present in winbase.h:4142, but available
is it already in winxp. Here's the doc link
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680345(v=vs.85).aspx
Also fixes duplicate bugs #54054 and #42098.
Furthermore this fixes incorrect error messages thrown from code
running inside an error handler when a compilation is in progress.
The error file and line are now correctly associated with the
file/line of the executor, rather than the compiler.
Without this fix, a webpage using eval() may return code 500. That might display
fine and the 500 go unnoticed, but using AJAX or wget, the 500 will cause problems.
