A few months back i submitted a bug report #21855 and forgotten about it.
In short ...certain complex enough scripts would cause PHP to crash and burn
on HPUX. The gdb backtraces and the fault generated seemed to indicate that
memory access was beging performed in the guard pages located just beyond
stack limits.
The bug has been fixed in our HP Apache distribution for sometime now.
The Problem:
HPUX has a default thread stack limit pitched at 64k on PARISC and 256k on
Itanium. For sufficiently complex scripts, I measured and found that PHP's
execution engine (execute() in zend_engine.c ) gets recursive and consumes
more than this default stack limit. The reason being that dynamic memory
allocation (for the opcodes?)is done on the stack instead of heap (for
performance reasons I guess).
This has showed up on HPUX easily perhaps due to its relatively smaller
default stack size. But in any case one cant count on PHP to be under the
stack limit
for "sufficiently complex" scripts on any OS as such which i beleive is
typically is KiloBytes. Increasing thread stack size at thread creation time
only (in apache)
delays the onset of problem and wastes memory for Apache threads that are
not
servicing PHP requests.
Solution:
Allocate from the heap, and take the performance hit.
********************************
<<< file 1: zend_execute.c
>>> file 2: fixed_zend_execute.c
********************************
-----[1015 changed to 1015]-----
< EX(Ts) = (temp_variable *)
do_alloca(sizeof(temp_variable)*op_array->T);
---
> EX(Ts) = (temp_variable *)
emalloc(sizeof(temp_variable)*op_array->T);
-----[1711 changed to 1711]-----
< free_alloca(EX(Ts));
---
> efree(EX(Ts));
--Roshan
