Red Hat Bugzilla – Bug 165837
PHP(4 and 5) core dumps (SSI including simple PHP)
Last modified: 2007-11-30 17:11:11 EST
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:
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..
(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
Can you include the complete stack trace from the crash?
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)
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 ***