|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2019-02-06 15:57 UTC] odoucet@php.net
Description:
------------
After upgrading a large website to PHP 7.2, we encountered several segfaults in logs. This does not reflect in front because it seems these errors happens on process shutdown/cleanup.
It is only happening with FPM (no problem on CGI).
The backtrace is available below.
It happens only on PHP 7.2 (no problem with tons of websites on 7.1).
Loaded modules when this happens :
[PHP Modules]
bcmath
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
hash
iconv
igbinary
imagick
intl
json
libxml
mbstring
mcrypt
memcache
memcached
msgpack
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
Reflection
session
SimpleXML
soap
sockets
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcache
It seems to happen when an additional module is loaded inside FPM :
php_admin_value[extension] = imagick.so
(but I was unable to test without).
Test script:
---------------
Expected result:
----------------
Working :)
Actual result:
--------------
Program terminated with signal 11, Segmentation fault.
#0 zend_string_release (s=0x0) at /usr/src/debug/php-7.2.14/Zend/zend_string.h:289
289 if (!ZSTR_IS_INTERNED(s)) {
Missing separate debuginfos, use: debuginfo-install systemd-libs-219-62.el7_6.2.x86_64
(gdb) bt
#0 zend_string_release (s=0x0) at /usr/src/debug/php-7.2.14/Zend/zend_string.h:289
#1 destroy_zend_class (zv=<optimized out>) at /usr/src/debug/php-7.2.14/Zend/zend_opcode.c:334
#2 0x000055dd5c01c540 in ?? ()
#3 0x000055dd5c37a6b0 in ?? ()
#4 0x000055dd5c01c540 in ?? ()
#5 0x000055dd5c37a7f0 in ?? ()
#6 0x000055dd5c2be291 in ?? ()
#7 0x000055dd5a3e9fd6 in zend_hash_destroy (ht=0x0) at /usr/src/debug/php-7.2.14/Zend/zend_hash.c:1247
#8 0x000055dd5a81a880 in ?? ()
#9 0x000055dd5a81a240 in ?? ()
#10 0x000055dd5c2be187 in ?? ()
#11 0x000055dd5a3d8151 in zend_shutdown () at /usr/src/debug/php-7.2.14/Zend/zend.c:911
#12 0x000055dd5c2be32f in ?? ()
#13 0x000055dd5a819d20 in ?? ()
#14 0x000055dd5c2be32f in ?? ()
#15 0x000055dd5a372f1b in php_module_shutdown () at /usr/src/debug/php-7.2.14/main/main.c:2453
#16 0x000055dd5a819d20 in ?? ()
#17 0x000055dd5a1e7ae1 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/php-7.2.14/sapi/fpm/fpm/fpm_main.c:2043
I was unable to find missing symbols, even after installing ALL symbols from package php* (we are using CentOS7 + repository remi-php72).
I kept backtrace available (privately) if it can help.
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Dec 21 16:01:28 2024 UTC |
It seems the backtrace is invalid. Here is the correct one : Program terminated with signal 11, Segmentation fault. #0 zend_string_release (s=0x0) at /usr/src/debug/php-7.2.14/Zend/zend_string.h:289 289 if (!ZSTR_IS_INTERNED(s)) { (gdb) bt full #0 zend_string_release (s=0x0) at /usr/src/debug/php-7.2.14/Zend/zend_string.h:289 No locals. #1 destroy_zend_class (zv=<optimized out>) at /usr/src/debug/php-7.2.14/Zend/zend_opcode.c:334 prop_info = <optimized out> ce = 0x55dd5c275250 fn = <optimized out> #2 0x000055dd5a3e9fd6 in zend_hash_destroy (ht=0x55dd5c01c540) at /usr/src/debug/php-7.2.14/Zend/zend_hash.c:1247 p = 0x55dd5c37a6b0 end = 0x55dd5c37a7f0 #3 0x000055dd5a3d8151 in zend_shutdown () at /usr/src/debug/php-7.2.14/Zend/zend.c:911 No locals. #4 0x000055dd5a372f1b in php_module_shutdown () at /usr/src/debug/php-7.2.14/main/main.c:2453 No locals. #5 0x000055dd5a1e7ae1 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/php-7.2.14/sapi/fpm/fpm/fpm_main.c:2043 exit_status = 0 c = <optimized out> use_extended_info = <optimized out> file_handle = {handle = {fd = -1241485312, fp = 0x7fb0b6007000, stream = {handle = 0x7fb0b6007000, isatty = 0, mmap = {len = 1265, pos = 0, map = 0x0, buf = 0x7fb0bb46d000 <Address 0x7fb0bb46d000 out of bounds>, old_handle = 0x0, old_closer = 0x0}, reader = 0x55dd5a38a920 <_php_stream_read>, fsizer = 0x55dd5a370b40 <php_zend_stream_fsizer>, closer = 0x55dd5a370b20 <php_zend_stream_mmap_closer>}}, filename = 0x7fb0b6003000 "00", opened_path = 0x0, type = ZEND_HANDLE_FILENAME, free_filename = 0 '\000'} orig_optind = <optimized out> orig_optarg = <optimized out> ini_entries_len = <optimized out> max_requests = 10000 requests = <optimized out> fcgi_fd = <optimized out> request = <optimized out> fpm_config = <optimized out> fpm_prefix = <optimized out> fpm_pid = <optimized out> test_conf = <optimized out> force_daemon = <optimized out> force_stderr = <optimized out> php_information = <optimized out> php_allow_to_run_as_root = <optimized out> __func__ = "main" I can confirm that moving the extension load from FPM to php.ini make the problem disappear. The issue should be on dynamic extension load by FPM.