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: Hello All, I have decided to try and rigorously cleanup the logic of the handler because it seems to have gotten out of hand actually. The new patch can be installed on 5.6.7. You can also get the code for sapi_apache2.c from https://github.com/gmoniker/php-apache2handler (the other files there are not changed.) The previous code has a goto. While goto's can be benificial for your code, they can also be a spaghetti monster in the making. This goto is of the latter category. And I am glad to say that after I worked through the code paths, it became clear that it could be removed along with a lot of other lines. Now I only did some serious testing on Apache 2.4 so far. It may be that this does not work with Apache 2.2. This solves two problems. One is the segfaults on Apache 2.4 with pipelined requests, and the other is the problem with segfaults on 413 ErrorDocuments in PHP in both Apache 2.2 and 2.4, where the initial request is also to PHP. This can be triggered by a LimitRequestBody and a PHP ErrorDocument which tries to introspect the symbol table, by doing for example: if (!defined('FOO')) define('BAR',1); To pipeline requests you can use this bash script: for var in "${@}"; do printf -- "GET /%s HTTP/1.1\nHost: localhost\n\n" "$var" done | nc localhost 80 gmoniker Gol Gol Previous Comments: ------------------------------------------------------------------------ [2015-03-23 00:17:34] gmoniker at gmail dot com 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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