Loop variables need to be freed for both "break" and "continue".
I'm adding the test to Zend/ because it's good to have a test for
this even without opcache.
This replaces the GUI element used for execution timeout handling
on Windows. Instead a timer queue technique is used, which is indeed
a thread pool. A timer queue timer is a lightweight object handled
but that thread pool and the timer thread spends most of the time
sleeping and waiting for an alert.
Please note also that this introduces neither binary nor source
breach. The custom timeout thread functions are deleted, however
they was not exported throug DLL, so couldn't be used by any
external code. As well they couldn't be used anywhere in the core
except in executor api, because those custom timeout thread
functions they used to operate on static variables which would
be overwritten (and that would blow).
So instead a relatively modern technique is used for the timeout
handling. It's still not perfect because the executor still has to
check EX(timed_out). This can be a topic for an improvement in
master. But brobably can be tricky as currently it seems to be not
possible to signal an individual thread. Also note another issue
that static variables aren't thread safe, but the current timer
implementation is.
With that, also fixed bug #68297 (Application Popup provides too few
information) as a better error message is provided to the event log.
In the second case, the condition for display_startup_error was removed. The
condition was added as a fix for bug #30760 which was preventing the
MessageBox to appear. When display_startup_error=on, the error will be seen
on the console. But when running under a webserver it'll probably get lost,
so we need to log it other way into the event log (would be done automatically
when message box was used, but that would eventually cause issues of blocked
execution).
Generally speaking - any MessageBox or other graphical element is a potential
issue and that was repeatedly reported. Graphical elements shouldn't be used
in the core. Even being a rare one it can cause a bad situation where the
server is blocked. Yet some places have to cleaned up.
* pull-request/840:
Update the VM generation script, per Bob.
Update NEWS after rebase.
Add BEGIN_EXTERN_C() and END_EXTERN_C() to .h files missing them.
* 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.
