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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
