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,
Too check for any differences in output between the present SAPI handler and a handler with the
second streamlining patch I made, I defined some baseline tests and executed them against the new
and old on both Apache 2.2 and Apache 2.4. I used the 5.6.7 patched version unchanged in 5.3.10, the
handler did not evolve in the meantime apart from quieting a compiler warning and setting a format
specifier by macro.
These tests show the output of the old handler and the new simplified handler to be the same :-)
You can lookup the tests at https://github.com/gmoniker/php-apache2handler
I enabled the includes module, and added a few lines to a standard config to get a Request Body
limit and 413 PHP errorhandler. There is also something interesting going on with Apache 2.4 if you
include an over the limit request body on the very first request to a worker. I leave this as an
exercise for the reader...
Previous Comments:
------------------------------------------------------------------------
[2015-03-24 23:58:09] gmoniker at gmail dot com
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
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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