php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #63355 PHP 5.3.x failes with core dump
Submitted: 2012-10-25 07:40 UTC Modified: 2014-12-30 10:41 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: rainer dot herbst at uni-potsdam dot de Assigned:
Status: No Feedback Package: Reproducible crash
PHP Version: 5.3.18 OS: Solaris 10 SPARC
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: rainer dot herbst at uni-potsdam dot de
New email:
PHP Version: OS:

 

 [2012-10-25 07:40 UTC] rainer dot herbst at uni-potsdam dot de 
Description:
------------
We use PHP 5.3.x with Apache HTTPD 2.4.3 on Oracle CMT Sparc systems for our elearning system (Moodle 2.3). Quite often, some httpd processes fails throwing core dumps causing sometimes the Solaris Service Manager to bring the HTTPD into maintenance mode. Sometimes only one core dump is written, sometimes up to 6-7 dumps simultanously. As to show how severe the problem is - in 12 hours we get app. 50 core dumps occuping app. 20 GB and 2-3 service "transitioned to maintenance" messages.

Both PHP and HTTPD were compiled using Solaris Studio 12.3. APC (3.1.9) is enabled. Configure line:
phpinfo()
PHP Version => 5.3.18

System => SunOS mymachine5 5.10 Generic_147440-15 sun4v
Build Date => Oct 24 2012 09:39:23
Configure Command =>  './configure'  '--with-apxs2=/opt/zeik/apache24/bin/apxs' '--disable-dba' '--disable-cgi' '--disable-debug' '--disable-dmalloc' '--disable-inline-optimization' '--disable-libgcc' '--disable-libtool-lock' '--disable-rpath' '--disable-static' '--enable-bcmath' '--enable-calendar' '--enable-ctype' '--enable-dom' '--enable-exif' '--enable-flatfile' '--enable-filter' '--enable-gd-jis-conv' '--enable-gd-native-ttf' '--enable-hash' '--enable-inifile' '--enable-ipv6' '--enable-json' '--enable-magic-quotes' '--enable-mbregex' '--enable-mbstring' '--enable-mod-charset' '--enable-pcntl' '--enable-posix' '--enable-libxml' '--without-sqlite' '--without-sqlite3' '--without-pdo-sqlite' '--enable-session' '--enable-shared' '--enable-shmop' '--enable-short-tags' '--enable-simplexml' '--enable-soap' '--enable-sockets' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-tokenizer' '--enable-xml' '--enable-xmlreader' '--enable-xmlwriter' '--enable-zend-multibyte' '--enable-zip' '--with-cdb' '--with-curlwrappers' '--with-freetype-dir=/usr' '--with-jpeg-dir=/usr' '--with-kerberos' '--with-layout=PHP' '--with-libxml-dir=/opt/zeik' '--with-pcre-regex' '--with-png-dir=/usr' '--with-xmlrpc' '--with-xpm-dir=/usr/openwin' '--with-xsl' '--with-zlib'
'--with-zlib-dir=/opt/zeik' '--without-dbm' '--with-pear' '--without-t1lib' '--with-freetype-dir=/opt/zeik' '--with-openssl-dir=/opt/zeik' '--enable-ftp=shared' '--enable-pdo=static' '--with-bz2=shared' '--with-gd=shared' '--with-gettext=shared' '--with-iconv=shared,/opt/zeik' '--without-imap' '--with-mcrypt=shared,/opt/zeik' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-mysql-sock=/tmp/mysql.sock' '--with-pdo-mysql=mysqlnd' '--without-tidy' '--with-curl=shared,/opt/zeik' '--with-imap-ssl=shared,/usr/sfw' '--with-ldap=shared,/opt/zeik' '--with-ldap-sasl=/opt/zeik' '--with-openssl=shared,/opt/zeik' '--without-snmp' '--enable-cli' '--disable-discard-path' '--prefix=/opt/zeik'


Due to the nature of the application, the memory limits have been increased:
 memory_limit = 1000M
 post_max_size = 1000M
 upload_max_filesize = 1000M
 apc.shm_size=256M

Other relevant settings in the php.ini
 default_socket_timeout = 1800
 extension=apc.so
 extension=bz2.so
 extension=curl.so
 extension=ftp.so
 extension=gd.so
 extension=gettext.so
 extension=iconv.so
 extension=ldap.so
 extension=mcrypt.so
 extension=openssl.so


pstack delivers the following message:
core 'mymachine5.1351146863.4020.httpd' of 4020:       /opt/zeik/apache24/sbin/httpd -k start -f /opt/site/etc/httpd/httpd.co
 fe256d98 zend_vm_stack_alloc (238, 0, 0, ec4063d0, 220f4f8, ec406430) + 110
 fe25b214 execute  (1f9e48, 2, ffc00000, 1, 440d78, 48) + b4
 fe1e728c zend_execute_scripts (2, 0, 1, ffbff458, 70687000, 7068702d) + 1bc
 fe2cf124 php_handler (500c00, e1, 0, 126958, 125288, 0) + 74c
 0005c534 ap_run_handler (500c00, 5017c0, 0, 1431f0, ffffffff, 1) + 8c
 0005d1c4 ap_invoke_handler (500c00, 0, 500bc0, 0, 0, 0) + 154
 0007da90 ap_process_async_request (500c00, 0, 4, 3b2f18, 0, 4) + 488
 0007dba4 ap_process_request (500c00, 4, 500c00, 501820, 0, 3b2f18) + 24
 00078edc ap_process_http_sync_connection (3b2f18, 3b31c0, 0, 3b2c80, 500c00, 3b31a8) + 7c
 0007903c ap_process_http_connection (3b2f18, 3b2c80, 3b2c80, 3b31c0, 0, 0) + 64
 0006c1f4 ap_run_process_connection (3b2f18, 3b2c80, 3b2c80, 143528, ffffffff, 0) + 8c
 0006c8c8 ap_process_connection (3b2f18, 3b2c80, 3b2c80, 1e, 3b0f58, 3b6c50) + 60
 0008746c child_main (1e, 86398, 0, da548, 3b2f18, 0) + 93c
 0008775c make_child (dfd18, 1e, 0, 0, 1cf4, feff8140) + 1f4
 00087820 startup_children (50, 2, 97fe4, 143440, 1e, 1) + 90
 00087f7c prefork_run (ba940, 11a108, dfd18, 0, 0, b4928) + 254
 000379bc ap_run_mpm (ba940, 11a108, dfd18, f2050, ffffffff, 0) + 9c
 0002e01c main     (5, ffbffcdc, ffbffcf4, ac800, ff290100, 0) + 12ec
 0002ba38 _start   (0, 0, 0, 0, 0, 0) + d8


Things I have tried:
PHP 5.3.17 - same behaviour
memory_limit decreased to 256MB - same behaviour

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-10-25 23:44 UTC] sixd@php.net 
As seems to be usual with cases involving APC, try to reproduce it _without_ APC.
You might also care to try the latest APC, though most of its fixes are probably 
for PHP 5.4.  

Thanks for the report but a testcase is really needed.
 [2012-10-25 23:44 UTC] sixd@php.net
-Status: Open +Status: Feedback
 [2012-10-30 12:01 UTC] rainer dot herbst at uni-potsdam dot de 
Compiled the latest APC version (3.1.13), but same behaviour:
- core dumps with
fe256d98 zend_vm_stack_alloc (1040, ffbff478, fe222de8, 0, 0, 0) + 110
- Service brought to maintenance modus every now and than.
 [2012-10-30 12:01 UTC] rainer dot herbst at uni-potsdam dot de
-Status: Feedback +Status: Open
 [2012-11-12 09:46 UTC] rainer dot herbst at uni-potsdam dot de 
Disabling APC does not solve the Problem. In both php 5.3. and 5.4 we still receive core dumps like this:

core '/var/cores/n-moodle2-6.1352712335.24296.httpd' of 24296:  /opt/zeik/apache24/sbin/httpd -k start -f /opt/site/etc/httpd/httpd.co
 fe09de40 zend_hash_find (fe646b24, 21b888, 25, ffbff180, ff0000, 6f646c65) + 50
 fe018e10 zend_set_compiled_filename (21b888, 2252, ffbff1f8, 21ba68, 24, 0) + 48
 fdfdbabc open_file_for_scanning (ffbff4c8, 1, ffc00000, 21b888, 0, 0) + 304
 fdfdbbec compile_file (ffbff4c8, 2, 0, 0, 21b7c8, 21b7c8) + 94
 fd9a20f0 phar_compile_file (ffbff4c8, 2, ffc00000, 800000, 540ba4, 48) + 3b8
 fe07e7e8 zend_execute_scripts (2, 0, 1, ffbff4c8, 70687000, 7068702d) + 140
 fe19e6dc php_handler (53ee28, e1, 0, 1231d8, 127920, 0) + 74c
 0005c534 ap_run_handler (53ee28, 53f9f0, 0, 1413b8, ffffffff, 1) + 8c
 0005d1c4 ap_invoke_handler (53ee28, 0, 53ede8, 0, 0, 0) + 154
 0007da90 ap_process_async_request (53ee28, 0, 4, 4b0870, 0, 4) + 488
 0007dba4 ap_process_request (53ee28, 4, 53ee28, 53fa50, 0, 4b0870) + 24
 00078edc ap_process_http_sync_connection (4b0870, 4b0b20, 0, 4b05d8, 53ee28, 4b0b08) + 7c
 0007903c ap_process_http_connection (4b0870, 4b05d8, 4b05d8, 4b0b20, 0, 0) + 64
 0006c1f4 ap_run_process_connection (4b0870, 4b05d8, 4b05d8, 1416f0, ffffffff, 0) + 8c
 0006c8c8 ap_process_connection (4b0870, 4b05d8, 4b05d8, 14, 4ae638, 4b45a8) + 60
 0008746c child_main (14, 86398, 0, da6d8, 4b0870, 0) + 93c
 0008775c make_child (dfd18, 14, 0, 0, 1cf4, fefb6100) + 1f4
 00087820 startup_children (20, 2, 97fe4, 1415f8, 14, 1) + 90
 00087f7c prefork_run (ba940, 11a108, dfd18, 0, 0, b4928) + 254
 000379bc ap_run_mpm (ba940, 11a108, dfd18, f2050, ffffffff, 0) + 9c
 0002e01c main     (5, ffbffd4c, ffbffd64, ac800, ff0e0100, 0) + 12ec
 0002ba38 _start   (0, 0, 0, 0, 0, 0) + d8


zend_hash_find is quite a short function, so it should not be so difficult to find the reason for this annoying instability...
 [2012-11-12 13:36 UTC] johannes@php.net 
Does this also happen without APC? Any chance to get som ereproduce code? hard to identify otherwise.
 [2012-11-12 13:36 UTC] johannes@php.net
-Status: Open +Status: Feedback
 [2012-11-12 14:25 UTC] rainer dot herbst at uni-potsdam dot de
-Status: Feedback +Status: Open
 [2012-11-12 14:25 UTC] rainer dot herbst at uni-potsdam dot de 
The core dumps with the "zend_hash_find" problem occure when APC is disabled. With APC enabled, we find "zend_vm_stack_alloc" in the core dumps.
 [2013-10-24 07:33 UTC] yohgaki@php.net
-Status: Open +Status: Feedback
 [2013-10-24 07:33 UTC] yohgaki@php.net 
Since we don't fix bugs in 5.3, could you try to see if 5.4 or later segfaults.
 [2014-12-30 10:41 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Wed Apr 24 04:01:30 2024 UTC