Bug 165837 - PHP(4 and 5) core dumps (SSI including simple PHP)
Summary: PHP(4 and 5) core dumps (SSI including simple PHP)
Keywords:
Status: CLOSED DUPLICATE of bug 168442
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 4
Hardware: athlon
OS: Linux
medium
high
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-12 18:36 UTC by Russell McOrmond
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-10-20 11:27:48 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Russell McOrmond 2005-08-12 18:36:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
I don't know if this can be considered a duplicate of the other bugs that are in bugzilla, but I thought I would let someone else determine this.  Doing a search finds a number of people tracking down what seem to be bugs in PHP (memory leaks) that are causing core dumps.

It is important for me to note that I was having this problem with the version of PHP4 from FC3 updates, and upgraded to PHP5 from FC4 in an attempt to "solve" the problem.  While the error seems to be happening in PHP I am suspect of the source being in some other support library.

I was running the FC3 version of PHP4 on FC4 because of version incompatabilities I was having with some scripts.  (See problem report at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163644 where a solution was found).

Everything was working until last evening when I (mistakenly?) updated some packages via YUM.  Unfortunately I wasn't watching as closely as I should have, so don't know what changed most recently.  I will likely check the dates on Fedora mirrors for things that were updated this month and see if I can step back in versions as a way to figure this out.



I have not been able to determine an exact pattern.  I have a number of .shtml pages which have an include at the top and bottom of a PHP snippit.


Example SSI and PHP source:
http://www.flora.ca/template/source.php3?demo.shtml
http://www.flora.ca/template/source.php3?template-top.php3
http://www.flora.ca/template/source.php3?template-bottom.php3


If you go to that demo page, it causes a segfault:

http://www.flora.ca/template/demo.shtml

#0  0x07b149df in yy_push_state (new_state=1)
    at Zend/zend_language_scanner.c:5990
5990            yy_start_stack[yy_start_stack_ptr++] = YY_START;
(gdb)

(Note: Most of the dumps fail at the same place...)

If I go to http://www.flora.ca/floss.shtml   it includes the template-top and shows body, but core dumps when trying to load the template-bottom.

Going to http://www.flora.ca/index.shtml  gets a core dump right away (No header, body or footer)


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. go to specific pages
2. get a core dump

Additional info:

Comment 1 Russell McOrmond 2005-08-12 18:47:34 UTC
I commented out the PHP in the include file, and it stopped core dumping.  I
don't quite know how a simple "if() {} else {}" could be causing so much
trouble, and suspect the problem is much deeper..


Comment 2 Russell McOrmond 2005-08-12 19:46:33 UTC
(Heading out for a bit, but wanted to post what I know so far in case it is
useful to someone ...)

  I downgraded HTTPD (and dependancies like apr and mod_ssl) from some '.1'
updates that came in recently, and the problem seems to have gone away for the
moment.


yum list updates (FC4) indicates the following:

Updated Packages
apr.i386                                 0.9.6-3.1              updates-released
httpd.i386                               2.0.54-10.1            updates-released
mod_ssl.i386                             1:2.0.54-10.1          updates-released

[root@newdelhi ~]# rpm -qa httpd\* mod_ssl\* apr\*

apr-0.9.6-3
httpd-2.0.54-10
apr-util-0.9.6-2
mod_ssl-2.0.54-10



Comment 3 Joe Orton 2005-08-15 09:02:28 UTC
Can you include the complete stack trace from the crash?

Comment 4 Russell McOrmond 2005-08-15 16:12:29 UTC
Correct me if I'm wrong, but since I have a different set of binaries/libraries
installed the 'bt' information won't be quite correct?

Do you have an easy suggestion for testing that doesn't involve me running the
.1 packages?  I could install the right /usr/sbin/httpd, but then it would link
to the wrong libapr which is where I'm suspecting the problem is.

Example core (I could generate them very easily when running the problem
binaries):  gdb /usr/sbin/httpd /tmp/core.6481

Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
 
warning: svr4_current_sos: Can't read pathname for load map: Input/output error
 
(no debugging symbols found)
Loaded symbols for /usr/sbin/httpd

...




#0  0x0754a40c in zend_hash_find (ht=0x75f0df0,
    arKey=0x86b2cec "", nKeyLength=1, pData=0x8695264)
    at /usr/src/debug/php-5.0.4/Zend/zend_hash.c:854
854                     if ((p->h == h) && (p->nKeyLength == nKeyLength)) {
(gdb) bt full
#0  0x0754a40c in zend_hash_find (ht=0x75f0df0, arKey=0x86b2cec "",
    nKeyLength=1, pData=0x8695264)
    at /usr/src/debug/php-5.0.4/Zend/zend_hash.c:854
        h = 2003329394
        p = (Bucket *) 0x1
#1  0x0752bd48 in zend_set_compiled_filename (
    new_compiled_filename=0x86b2c94
"/home/digital-copyright.ca/www.digital-copyright.ca/static/template/template-bottom.php3")
    at /usr/src/debug/php-5.0.4/Zend/zend_compile.c:184
        pp = Variable "pp" is not available.
(gdb) bt
#0  0x0754a40c in zend_hash_find (ht=0x75f0df0, arKey=0x86b2cec "",
    nKeyLength=1, pData=0x8695264)
    at /usr/src/debug/php-5.0.4/Zend/zend_hash.c:854
#1  0x0752bd48 in zend_set_compiled_filename (
    new_compiled_filename=0x86b2c94
"/home/digital-copyright.ca/www.digital-copyright.ca/static/template/template-bottom.php3")
    at /usr/src/debug/php-5.0.4/Zend/zend_compile.c:184
#2  0x0752590a in open_file_for_scanning (file_handle=0xbfbe4c50)
    at Zend/zend_language_scanner.c:3109
#3  0x07525df1 in compile_file (file_handle=0xbfbe4c50, type=2)
    at Zend/zend_language_scanner.c:3145
#4  0x07541653 in zend_execute_scripts (type=2, retval=0x0, file_count=1)
    at /usr/src/debug/php-5.0.4/Zend/zend.c:1065
#5  0x0757cc2f in php_handler (r=0x86b35b0)
    at /usr/src/debug/php-5.0.4/sapi/apache2handler/sapi_apache2.c:572
#6  0x00fabf3c in ap_run_handler () from /usr/sbin/httpd
#7  0x00fac2d7 in ap_invoke_handler () from /usr/sbin/httpd
#8  0x00fc4b41 in ap_destroy_sub_req () from /usr/sbin/httpd
#9  0x00ab0c58 in ?? () from /etc/httpd/modules/mod_include.so
#10 0x00ab4993 in ?? () from /etc/httpd/modules/mod_include.so
#11 0x00fb9994 in ap_pass_brigade () from /usr/sbin/httpd
#12 0x00fc0c4a in ap_core_translate () from /usr/sbin/httpd
#13 0x086a01a8 in ?? ()
---Type <return> to continue, or q <return> to quit---
#14 0x00002883 in ?? ()
#15 0x08699c90 in ?? ()
#16 0x08697c88 in ?? ()
#17 0xffffffff in ?? ()
#18 0x00000000 in ?? ()
(gdb)

Comment 5 Joe Orton 2005-10-20 11:27:48 UTC
OK, found the bug; multiple inclusion of PHP pages from SSI; duping against the
more succint report.

*** This bug has been marked as a duplicate of 168442 ***


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