Bug 168442

Summary: page crashed when include 2 or more .php files in a shtml page
Product: [Fedora] Fedora Reporter: Colnodo <omar>
Component: phpAssignee: Joe Orton <jorton>
Status: CLOSED CURRENTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: russell, thierry.lach
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: http://mail.omartinez.net/bug_sample/
Whiteboard:
Fixed In Version: php-5.1.4-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-29 00:24:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Colnodo 2005-09-16 00:24:56 UTC
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:
Always

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 11:28:03 UTC
*** Bug 165837 has been marked as a duplicate of this bug. ***

Comment 2 Russell McOrmond 2005-12-04 03:00:47 UTC
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 13:45:42 UTC
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 14:55:32 UTC
Thanks.  Look forward to testing the update.


Comment 5 Russell McOrmond 2006-02-12 16:53:15 UTC
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
httpd-2.0.54-10
mod_ssl-2.0.54-10

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

# rpm -qa | grep php
php-mysql-5.0.4-10.5
php-5.0.4-10.5
php-xml-5.0.4-10.5
php-pear-5.0.4-10.5
php-xmlrpc-5.0.4-10.5
php-mbstring-5.0.4-10.5
php-ldap-5.0.4-10.5
php-imap-5.0.4-10.5
php-devel-5.0.4-10.5



Comment 6 Russell McOrmond 2006-05-06 16:06:05 UTC
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
httpd.

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/

Source: 

http://www.flora.org/flora/template/source.php3?template-top.php3
http://www.flora.org/flora/template/source.php3?demo.shtml
http://www.flora.org/flora/template/source.php3?template-bottom.php3


Comment 7 Joe Orton 2006-05-10 13:52:01 UTC
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 14:13:52 UTC
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
problems.

httpd-2.0.54-10.3
mod_ssl-2.0.54-10.3
php-5.0.5-2.2

Comment 9 Russell McOrmond 2006-05-12 03:08:34 UTC
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 14:26:40 UTC
A quick note.  I have since upgraded from FC4 to FC5, with the problems not
being in these newer packages provided with FC5.

php-5.1.4-1
httpd-2.2.2-1.2

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



Comment 11 Christian Iseli 2007-01-22 11:39:13 UTC
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 ?

Thanks.

Comment 12 Russell McOrmond 2007-01-22 17:36:27 UTC
This problem was fixed in newer releases, and can be closed.


Comment 13 petrosyan 2008-02-29 00:24:00 UTC
Closing as requested in comment #12.