Bug #68486 [Com]: PHP SegFault zend_hash_find

Edit report at https://bugs.php.net/bug.php?id=68486&edit=1 ID: 68486 Comment by: gmoniker at gmail dot com Reported by: wattwood at tcstire dot com Summary: PHP SegFault zend_hash_find Status: Open Type: Bug Package: Apache2 related Operating System: Ubuntu 14.04.1 LTS PHP Version: 5.5.19 Block user comment: N Private report: N New Comment: I have been looking at the situations where the SAPI apache2 handler can enter the PHP handling with a PHP context set. These are: (Apache 2.4 only) Client connection does not drop and a previous PHP request has not had its complete output flushed by a new request on the same client connection with sufficient output to bust the buffer. (Apache 2.2 and 2.4) 1. Running "inside" an original PHP handled client request. a. When entering a virtual() of the request b. Abnormal ending of the initial request PHP handling AND Apache has fired an ErrorDocument set to a PHP artefact. 2. Running inside an SSI template a. A virtual() of an initial PHP script call b. Subsequent request to a PHP script or its subrequests BUT there may be no active SAPI yet: This happens when an SSI includes several PHP scripts in series. Each time the processing returns to the host SSI template itself the SAPI is deactivated, but on entering the next PHP script call a context remains visible that was allocated by the last PHP script. In all cases except the specific Apache 2.4 case the SAPI will be activated before using it. But for a 413 ErrorDocument it is tried to reuse the previous SAPI instance. Entering a virtual that has a compile error will segfault. Using the oneline patch solves the Apache 2.4 specific case, it shortens the path of code that SSI templates run through when they have sequential PHP scripts, and it stops the handler from trying to reuse the previous PHP instance in case of a 413 handler in PHP responding to a PHP script that Apache throws a 413 error for. (Setting 413 status yourself does not call the 413 ErrorDocument). But some more rewriting of the handler and the Virtual function is needed. Previous Comments: ------------------------------------------------------------------------ [2015-03-20 13:31:40] phpdev at ehrhardt dot nl The same one-liner fixed segfaults in Apache 2.4.12 64-bit on Windows 2008 R2 with PHP 5.6.7 64-bit as mod_php. I could make it segfault from a remote Linux server... ------------------------------------------------------------------------ [2015-03-19 18:59:04] php at bof dot de Related To: Bug #69218 ------------------------------------------------------------------------ [2015-03-19 14:58:20] phpdev at ehrhardt dot nl I applied the 1 line patch at https://bugs.php.net/patch-display.php?bug_id=68486&patch=sapi_apache2.gmoniker.patch&revision=latest to my Centos6, Apache 2.4.12 with PHP 5.6.6 as mod_php and the segfaults vanished as well. ------------------------------------------------------------------------ [2015-03-19 07:52:51] php at bof dot de Everything is running smoothly with the one-line patch attached yesterday (thanks again gmoniker!). That is on two different (same load) production boxes, one with Apache 2.2 and one with Apache 2.4. No segfaults, no CPU usage or memory usage or latency issues (I've got them covered pretty thoroughly in Nagios). I think this is ready to go into the next 5.5.x, 5.6.x, and master. ------------------------------------------------------------------------ [2015-03-18 22:39:33] gmoniker at gmail dot com @bof, Thanks for your hard work! I still don't know exactly when the first request pool is destroyed by the EOR bucket. It might be when the output of the next request begins to run. Anyway this is a very necessary patch for using Apache 2.4. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=68486 -- Edit this bug report at https://bugs.php.net/bug.php?id=68486&edit=1