Bug 468634

Summary: Stack overflow in PHP 5.2.6 x86_64: Can't grow stack
Product: [Fedora] Fedora Reporter: Stephen Cuppett <steve>
Component: phpAssignee: Joe Orton <jorton>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: fedora, jorton, rpm
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-28 08:51:15 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 Stephen Cuppett 2008-10-27 00:25:45 UTC
Description of problem:

Was receiving a segfault in Apache when using mod_php5 on Fedora 9 x86_64.  Application uses php-soap, php-pgsql, php-mysql.  Turned off SELinux and adjusted /etc/init.d/httpd to run valgrind to see where it was blowing up.

I received this output from valgrind:

==23996== Stack overflow in thread 1: can't grow stack to 0x7FE601FF8
==23996== Can't extend stack to 0x7FE601700 during signal delivery for thread 1:
==23996==   no stack segment
==23996== 
==23996== Process terminating with default action of signal 11 (SIGSEGV)
==23996==  Access not within mapped region at address 0x7FE601700
==23996==    at 0xC9B1D8C: (within /usr/lib64/httpd/modules/libphp5.so)
==23996== 
==23996== Invalid write of size 8
==23996==    at 0x4802338: _vgnU_freeres (vg_preloaded.c:56)
==23996==  Address 0x7fe601f70 is on thread 1's stack
==23996== Stack overflow in thread 1: can't grow stack to 0x7FE601F70
==23996== 
==23996== Process terminating with default action of signal 11 (SIGSEGV)
==23996==  Access not within mapped region at address 0x7FE601F70
==23996==    at 0x4802338: _vgnU_freeres (vg_preloaded.c:56)


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

httpd-2.2.9-1.fc9.x86_64
php-5.2.6-2.fc9.x86_64
php-soap-5.2.6-2.fc9.x86_64
php-pgsql-5.2.6-2.fc9.x86_64
php-mysql-5.2.6-2.fc9.x86_64
php-common-5.2.6-2.fc9.x86_64 

How reproducible:

Seems specific to a certain set of pages in my applicaton.  Pages don't seem to have a memory problem in their own right, also, PHP has it's own set of memory restrictions to usually keep a user created page from segfaulting the thread.

Actual results:

Process terminating with default action of signal 11 (SIGSEGV)

Expected results:

PHP generated error and/or successful completion of the request.

Additional info:

Intel Core 2 Quad Q6600 2.4Ghz
4GB main memory DDR2 800 Mhz
Intel P35 chipset
[root@home init.d]# cat /proc/swaps
Filename				Type		Size	Used	Priority
/dev/sdb2                               partition	4192956	84	-1


Would like to help diagnose, but need additional instructions as to what you'd need.  Are there httpd and php packages to point to with symbols so that valgrind can give more information???... extra options to use with valgrind?

Comment 1 Stephen Cuppett 2008-10-27 00:30:01 UTC
This is all I receive in the HTTP error log:

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

Comment 2 Joe Orton 2008-10-27 10:43:13 UTC
Stack overflows in PHP are usually caused by a recursive function call, which will consume available stack space.  Can you add

  CoreDumpDirectory /tmp

to your httpd.conf, restart, trigger the issue, and get a backtrace from the core dump in /tmp.

Comment 3 Stephen Cuppett 2008-10-27 22:55:10 UTC
Should I run with that command with valgrind?.. or without?  I added the command and tried without valgrind.  This page didn't seem to indicate gdb or anything had to be attached (I also ran the ulimit command):

http://httpd.apache.org/dev/debugging.html#backtrace

When I added the command I got nothing in /tmp.  I turned SELinux off again just in case that was an issue.

I tried attaching to the first thread with gdb and got the request, then I only saw this:

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x000000001085ef45 in ?? () from /etc/httpd/modules/libphp5.so

Comment 4 Stephen Cuppett 2008-10-27 23:11:59 UTC
Sorry, forgot the "where".  

Program received signal SIGSEGV, Segmentation fault.
0x000000000dc89256 in ?? () from /usr/lib64/php/modules/soap.so
(gdb) where
#0  0x000000000dc89256 in ?? () from /usr/lib64/php/modules/soap.so
#1  0x0000000054569f7b in zend_error_noreturn ()
   from /etc/httpd/modules/libphp5.so
#2  0x000000005459fcd3 in ?? () from /etc/httpd/modules/libphp5.so
#3  0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#4  0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#5  0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#6  0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#7  0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#8  0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#9  0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#10 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#11 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#12 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#13 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#14 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#15 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#16 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#17 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#18 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#19 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#20 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#21 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#22 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#23 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#24 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#25 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#26 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#27 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#28 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#29 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#30 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#31 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#32 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#33 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#34 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#35 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#36 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#37 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#38 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#39 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#40 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#41 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#42 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#43 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#44 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so

Comment 5 Stephen Cuppett 2008-10-27 23:17:45 UTC
The end of the stack has:

#9566 0x00000000545a183e in ?? () from /etc/httpd/modules/libphp5.so
#9567 0x000000005458d454 in execute () from /etc/httpd/modules/libphp5.so
#9568 0x00000000545697b8 in zend_execute_scripts () from /etc/httpd/modules/libphp5.so
#9569 0x0000000054525222 in php_execute_script () from /etc/httpd/modules/libphp5.so
#9570 0x00000000545dee03 in ?? () from /etc/httpd/modules/libphp5.so
#9571 0x00007fc32b74a0a3 in ap_run_handler () from /usr/sbin/httpd
#9572 0x00007fc32b74d77f in ap_invoke_handler () from /usr/sbin/httpd
#9573 0x00007fc32b758b00 in ap_internal_redirect () from /usr/sbin/httpd
#9574 0x0000000007d4d7e5 in ap_make_dirstr_parent () from /etc/httpd/modules/mod_rewrite.so
#9575 0x00007fc32b74a0a3 in ap_run_handler () from /usr/sbin/httpd
#9576 0x00007fc32b74d77f in ap_invoke_handler () from /usr/sbin/httpd
#9577 0x00007fc32b758b00 in ap_internal_redirect () from /usr/sbin/httpd
#9578 0x0000000007d4d7e5 in ap_make_dirstr_parent () from /etc/httpd/modules/mod_rewrite.so
#9579 0x00007fc32b74a0a3 in ap_run_handler () from /usr/sbin/httpd
#9580 0x00007fc32b74d77f in ap_invoke_handler () from /usr/sbin/httpd
#9581 0x00007fc32b758cde in ap_process_request () from /usr/sbin/httpd
#9582 0x00007fc32b755bf8 in ?? () from /usr/sbin/httpd
#9583 0x00007fc32b7519b3 in ap_run_process_connection () from /usr/sbin/httpd
#9584 0x00007fc32b75d64e in ?? () from /usr/sbin/httpd
#9585 0x00007fc32b75d8fa in ?? () from /usr/sbin/httpd
#9586 0x00007fc32b75e0a8 in ap_mpm_run () from /usr/sbin/httpd
#9587 0x00007fc32b7363fd in main () from /usr/sbin/httpd

Comment 6 Joe Orton 2008-10-28 08:50:14 UTC
That's clearly some kind of recursive function call, though it doesn't look like the normal stack trace from a PHP-function-calls-self (see e.g. bug 463858); may be something more subtle, but it's clearly a script issue either way.

If you "debuginfo-install php httpd" then you can jump up to one of those ap_* frames and e.g. print r->filename to see what script is causing this.