php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #74682 http fails to start with segmentation fault, only a reboot fixed !
Submitted: 2017-05-31 16:30 UTC Modified: 2021-08-01 04:22 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: response at ifastnet dot com Assigned: cmb (profile)
Status: No Feedback Package: Apache2 related
PHP Version: 7.0.19 OS: Linux (Centos 6 )
Private report: No CVE-ID: None
 [2017-05-31 16:30 UTC] response at ifastnet dot com
Description:
------------
Hi All,

Hope someone can help. 

We have recently started to have an issue with php version 7.0.16++, after around 10 days of uptime httpd dies and refuses to start up no matter what, the only way to get httpd to start up is rebooting. 

Running a backtrace on the faulted serverI get the following 

[root@freeweb19 ~]# gdb /opt/rh/httpd24-php70/root/usr/sbin/httpd
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-92.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/rh/httpd24-php70/root/usr/sbin/httpd...Missing separate debuginfo for /opt/rh/httpd24-php70/root/usr/sbin/httpd
Try: yum --enablerepo='*-debug*' install /usr/lib/debug/.build-id/1e/94d34726457e3ad4feeed01ebb7dedd53d4152.debug
(no debugging symbols found)...done.
(gdb) run -X
Starting program: /opt/rh/httpd24-php70/root/usr/sbin/httpd -X
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7f7c000
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe5fcb700 (LWP 95589)]
[Thread 0x7fffe5fcb700 (LWP 95589) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007fffeab83d87 in _emalloc_24 () at /root/php-7.0.19/Zend/zend_alloc.c:2380
2380	ZEND_MM_BINS_INFO(_ZEND_BIN_ALLOCATOR, x, y)
Missing separate debuginfos, use: debuginfo-install audit-libs-2.4.5-6.el6.x86_64 cyrus-sasl-lib-2.1.23-15.el6_6.2.x86_64 db4-4.7.25-22.el6.x86_64 expat-2.0.1-13.el6_8.x86_64 freetype-2.3.11-17.el6.x86_64 glibc-2.12-1.209.el6_9.1.x86_64 httpd24-apr-1.5.2-3.el6.x86_64 httpd24-apr-util-1.5.4-5.el6.x86_64 httpd24-apr-util-mysql-1.5.4-5.el6.x86_64 httpd24-httpd-2.4.18-11.el6.cloudlinux.1.x86_64 httpd24-mod_hostinglimits-1.0-31.el6.cloudlinux.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-65.el6.x86_64 libattr-2.4.44-7.el6.x86_64 libc-client-2007e-11.el6.x86_64 libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-23.el6.x86_64 libgcc-4.4.7-18.el6.x86_64 libgcrypt-1.4.5-12.el6_8.x86_64 libgpg-error-1.7-4.el6.x86_64 libidn-1.18-2.el6.x86_64 libjpeg-turbo-1.2.1-3.el6_5.x86_64 liblve-1.4-1.21.el6.cloudlinux.x86_64 libmcrypt-2.5.8-9.el6.x86_64 libpng-1.2.49-2.el6_7.x86_64 libselinux-2.0.94-7.el6.x86_64 libstdc++-4.4.7-18.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 libuuid-2.17.2-12.28.el6.x86_64 libxml2-2.7.6-21.el6_8.1.x86_64 libxslt-1.1.26-2.el6_3.1.x86_64 mysql-libs-5.1.73-8.el6_8.cloudlinux.x86_64 nspr-4.13.1-1.el6.x86_64 nss-3.28.4-1.el6_9.x86_64 nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64 nss-util-3.28.4-1.el6_9.x86_64 openldap-2.4.40-16.el6.x86_64 openssl-1.0.1e-57.el6.x86_64 pam-1.1.1-24.el6.x86_64 pcre-7.8-7.el6.x86_64 perl-libs-5.10.1-144.el6.x86_64 t1lib-5.1.2-6.el6_2.1.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x00007fffeab83d87 in _emalloc_24 () at /root/php-7.0.19/Zend/zend_alloc.c:2380
#1  0x00007fffeac3ef31 in zend_hash_str_update_mem (cmd=<value optimized out>, dummy=0x7ffff82c0f70, name=0x7ffff82c0fc8 "default_socket_timeout", 
    value=0x7ffff82c0fe0 "3", status=4) at /root/php-7.0.19/Zend/zend_hash.h:614
#2  real_value_hnd (cmd=<value optimized out>, dummy=0x7ffff82c0f70, name=0x7ffff82c0fc8 "default_socket_timeout", value=0x7ffff82c0fe0 "3", status=4)
    at /root/php-7.0.19/sapi/apache2handler/apache_config.c:73
#3  0x00007ffff7fc79c4 in ?? ()
#4  0x00007ffff7fc9333 in ap_walk_config ()
#5  0x00007ffff7fb78e0 in ?? ()
#6  0x00007ffff7fc77e6 in ?? ()
#7  0x00007ffff7fc9333 in ap_walk_config ()
#8  0x00007ffff7fc97d9 in ap_process_config_tree ()
#9  0x00007ffff7fa30dc in main ()

I can confim I have 

php_admin_value default_socket_timeout 3

in the httpd.conf, however the segmentation fault basically complains about the first defined instance of any php_admin_value that is set in the config file. 

I can configrm that when trying to start httpd there is no other httpd processes running, howevber the segmentation fault / backtrace is the same if running and re-running the bactrace, only rebooting the server does in the end fix the problem and allow httpd to start. 

Server is running httpd 2.4.18 and php 7.0.19, and this affects multiple servers.


Test script:
---------------
Unfortunatly there is no test script 

Expected result:
----------------
No segmentation fault

Actual result:
--------------
Segmentation fault

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-05-31 17:14 UTC] response at ifastnet dot com
Hi, just adding valgrind output from a failed instance 

USE_ZEND_ALLOC=0 valgrind /opt/rh/httpd24-php70/root/usr/sbin/httpd -X
==994134== Memcheck, a memory error detector
==994134== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==994134== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==994134== Command: /opt/rh/httpd24-php70/root/usr/sbin/httpd -X
==994134== 
==994134== Warning: noted but unhandled ioctl 0x7 with no size/direction hints
==994134==    This could cause spurious value errors to appear.
==994134==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==994134== Warning: noted but unhandled ioctl 0x7 with no size/direction hints
==994134==    This could cause spurious value errors to appear.
==994134==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==994134== Warning: noted but unhandled ioctl 0x7 with no size/direction hints
==994134==    This could cause spurious value errors to appear.
==994134==    See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a proper wrapper.
==994134== Invalid read of size 4
==994134==    at 0x11DB4D87: _emalloc_24 (zend_alloc.c:2380)
==994134==    by 0x11E6FF30: real_value_hnd (zend_hash.h:614)
==994134==    by 0x14D9C3: ??? (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14F332: ap_walk_config (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x13D8DF: ??? (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14D7E5: ??? (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14F332: ap_walk_config (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14F7D8: ap_process_config_tree (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x1290DB: main (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==994134== 
==994134== 
==994134== Process terminating with default action of signal 11 (SIGSEGV)
==994134==  Access not within mapped region at address 0x0
==994134==    at 0x11DB4D87: _emalloc_24 (zend_alloc.c:2380)
==994134==    by 0x11E6FF30: real_value_hnd (zend_hash.h:614)
==994134==    by 0x14D9C3: ??? (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14F332: ap_walk_config (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x13D8DF: ??? (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14D7E5: ??? (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14F332: ap_walk_config (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x14F7D8: ap_process_config_tree (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==    by 0x1290DB: main (in /opt/rh/httpd24-php70/root/usr/sbin/httpd)
==994134==  If you believe this happened as a result of a stack
==994134==  overflow in your program's main thread (unlikely but
==994134==  possible), you can try to increase the size of the
==994134==  main thread stack using the --main-stacksize= flag.
==994134==  The main thread stack size used in this run was 10485760.
==994134== 
==994134== HEAP SUMMARY:
==994134==     in use at exit: 748,195 bytes in 535 blocks
==994134==   total heap usage: 725 allocs, 190 frees, 938,287 bytes allocated
==994134== 
==994134== LEAK SUMMARY:
==994134==    definitely lost: 0 bytes in 0 blocks
==994134==    indirectly lost: 0 bytes in 0 blocks
==994134==      possibly lost: 599,324 bytes in 97 blocks
==994134==    still reachable: 148,871 bytes in 438 blocks
==994134==         suppressed: 0 bytes in 0 blocks
==994134== Rerun with --leak-check=full to see details of leaked memory
==994134== 
==994134== For counts of detected and suppressed errors, rerun with: -v
==994134== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 278 from 10)
Segmentation fault
 [2021-07-21 14:21 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-07-21 14:21 UTC] cmb@php.net
Does this still happen to you with any of actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2021-08-01 04:22 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: Sat Dec 07 11:01:27 2024 UTC