Bug 168442 - page crashed when include 2 or more .php files in a shtml page
page crashed when include 2 or more .php files in a shtml page
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
: 165837 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-09-15 20:24 EDT by Colnodo
Modified: 2008-02-28 19:24 EST (History)
2 users (show)

See Also:
Fixed In Version: php-5.1.4-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-28 19:24:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Colnodo 2005-09-15 20:24:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
When you try to include 2 or more .php pages in a SSI (.shtml) page the page does not load correctly and a error is logged

[notice] child pid xxxx exit signal Segmentation fault (11)

Version-Release number of selected component (if applicable):
httpd-2.0.54-10.2 php-5.0.4-10.4

How reproducible:

Steps to Reproduce:
1. Create .php in a location of your webserver.
2. Create a .shtml file in a different location of your webserver
3. Include twice the same file using 
  <!--#include virtual="/path/to/your/php_file.php"-->
4.- Don't forget to activate the Includes Options
5.- Try to load the .shtml page in a browser using http protocol
6.- Check your error_log file

Actual Results:  The page doesn't load.

Expected Results:  The page with the 2 .php files content processed.

Additional info:

The .php includes mut be in diferent directories. If this includes are in the same level than the .shtml file the page is displayed all right.
Comment 1 Joe Orton 2005-10-20 07:28:03 EDT
*** Bug 165837 has been marked as a duplicate of this bug. ***
Comment 2 Russell McOrmond 2005-12-03 22:00:47 EST
Joe Orton,

Have you been able to confirm this bug at your end?  I've been sticking with the
earlier version of HTTPD as this problem makes the .1 release unusable.

Comment 3 Joe Orton 2005-12-05 08:45:42 EST
Yes we know what's causing this, thanks.  It should be possible to fix this in
the next php update.
Comment 4 Russell McOrmond 2005-12-05 09:55:32 EST
Thanks.  Look forward to testing the update.
Comment 5 Russell McOrmond 2006-02-12 11:53:15 EST
I am wondering if anyone is working on this.  I'm not convinced this is a PHP
problem as there have been updates to PHP and they don't seem to change the
problem one way or the other.

I did a full update on another machine to the latest FC4 packages, and saw the
same problem.  I backed up the httpd and the mod_ssl dependency and the problem
went away. Whatever the change is it was introduced with the ".1" update and is
still there with the ".3" update to httpd.

Yum says: Updated Packages
httpd.i386    2.0.54-10.3            updates-released
mod_ssl.i386  1:2.0.54-10.3          updates-released

I am currently running (as those updates cause the core dump): rpm -q httpd mod_ssl

I'm running the latest PHP without any problems now that I've went to the older
version of httpd.

# rpm -qa | grep php

Comment 6 Russell McOrmond 2006-05-06 12:06:05 EDT
This bug needs to be changed to claify that is not a PHP but, but a bug in some
RedHat patch to Apache.  The "component" is set to php when it should be set to

I have a number of machines running FC4 which I can not upgrade the httpd (and 
mod_ssl dependency) because of this problem. I can upgrade versions of PHP and
this has no affect on this problem.

Updated Packages listed from 'yum list updates':

httpd.i386           2.0.54-10.3      updates-released
mod_ssl.i386         1:2.0.54-10.3    updates-released

The packages cause the core dump:

The packages I'm currently running that work:
httpd-2.0.54-10.i386.rpm  mod_ssl-2.0.54-10.i386.rpm

Sample SSI that causes core dump can be seen at http://www.flora.org/flora/template/


Comment 7 Joe Orton 2006-05-10 09:52:01 EDT
The bug is caused by a fix to mod_include which was backported to the FC4 httpd.

The php in updates-testing should fix this, please try:

# yum --enablerepo=updates-testing php
Comment 8 Russell McOrmond 2006-05-10 10:13:52 EDT
I am running the test version of PHP and the update version of httpd, and it
seems to be working.

Will leave things running with the new version, and see if I observe any other

Comment 9 Russell McOrmond 2006-05-11 23:08:34 EDT
I need to do some more testing, but the upgrade from php-5.0.4-10.5 to
php-5.0.5-2.2 broke some php scripts.  I don't know if it is because some
default settings have changed or if there are bugs (in the new PHP or in the PHP
scripts), but I've been forced to temporarily revert in versions.

Comment 10 Russell McOrmond 2006-08-18 10:26:40 EDT
A quick note.  I have since upgraded from FC4 to FC5, with the problems not
being in these newer packages provided with FC5.


I don't have other FC4 machines I'm administering, so won't be able to help in

Comment 11 Christian Iseli 2007-01-22 06:39:13 EST
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Comment 12 Russell McOrmond 2007-01-22 12:36:27 EST
This problem was fixed in newer releases, and can be closed.
Comment 13 petrosyan 2008-02-28 19:24:00 EST
Closing as requested in comment #12.

Note You need to log in before you can comment on or make changes to this bug.