devnexen
commented
1 month ago Hi
The opcache.protect_memory string does not affect crashes.
are you using opcache JIT ?
Closed shm-dmitry closed 1 month ago
devnexen
commented
1 month ago Hi
The opcache.protect_memory string does not affect crashes.
are you using opcache JIT ?
shm-dmitry
commented
1 month ago @devnexen
Hi, JIT is disabled
iluuu1994
commented
1 month ago Hi @shm-dmitry! Can you try disabling observers? The stack trace itself is not super indicative of the error, because it is likely cause by a buffer overwrite in some other place. If you can reproduce the error locally, you could try compiling PHP with the --enable-address-sanitizer flag, set the USE_ZEND_ALLOC=0 environment variable, and see if you get a more useful error.
dstogov
commented
1 month ago You got a heap corruption because of use-after-free or double free. Very probably (but not necesarry) this occurs because of a bug in third-party PHP extension. Unfortunately your backtrace doesn't shows the source of the real failure. Running your app with with some heap debugger (address sanitizer or valgrind) may give more info.
shm-dmitry
commented
1 month ago @dstogov , this is production server with old operation system. I tried to compile php, but I was having problems with dependencies. Maybe we can transfer it to a actual ubuntu and compile it there, but it's a complicated process.
Modules list
[PHP Modules]
calendar
Core
ctype
curl
date
dom
exif
FFI
fileinfo
filter
ftp
gd
gettext
hash
iconv
imagick
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
soap
sockets
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcacheI see, you don't use third-party extensions, so the bug should be in the mai PHP source tree.
I know, it's really hard to localize this kind of bugs, but they hardly ever can be fixed without a reproduction case.
Localization of the invalid free() may be only the first step of debugging, because it may be caused by invalid reference-counting or interaction with garbage collectior...
shm-dmitry
commented
1 month ago @dstogov , I'm sorry, but my previous modules list was from another server.
There are actual modules list.
I see XDebug - can it help you?
[PHP Modules]
apcu
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
geoip
gettext
hash
iconv
intl
json
ldap
libxml
mbstring
mcrypt
memcache
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
pspell
random
readline
Reflection
rrd
session
shmop
SimpleXML
sockets
sodium
SPL
sqlite3
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xdebug
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Xdebug
Zend OPcacheThis won't help me to identify the problem, but now I see third-party extensions that may be the source of failure.
shm-dmitry
commented
1 month ago I can try to disable it, which modules are you talking about? I saw
extension=zip.so
extension = apcu.so
extension=geoip.so
extension=memcache.so
extension=rrd.so
zend_extension=opcache.so
zend_extension=xdebug.soI've seen some problems with the geo-ip extension somewhere, I'll try to disable it.
dstogov
commented
1 month ago Most probably the "bad" extension is used by your app and won't work without it. Even if you find the "bad" extension, it won't help to identify the bug there. The only way to start debugging is identifying the consistent reproduction scenario...
iluuu1994
commented
1 month ago @shm-dmitry You might want to try to remove Xdebug at least, which should generally not be installed in your production environment.
shm-dmitry
commented
1 month ago @iluuu1994 , yes, I disabled xdebug, and no crashes have occurred in the last hour. I am continuing to check this now and will write a message when I am sure of the result.
shm-dmitry
commented
1 month ago I waited for a while and ran some tests, and now I'm sure the problem was in the xdebug module.
I do not know how it corruptes memory, because no one uses it, but turning on this module leads to a crash, and when I turn it off, I cannot reproduce this crash.
Versions:
php.x86_64 8.3.8-1.el7.remi @remi-php83
php-debuginfo.x86_64 8.3.8-1.el7.remi @remi-php83-debuginfo
php-pecl-xdebug3.x86_64 3.3.2-1.el7.remi.8.3 @remi-php83
php-pecl-xdebug3-debuginfo.x86_64 3.3.2-1.el7.remi.8.3 @remi-php83-debuginfoI think this issue can be closed due to a problem (probably?) in the external module. I can answer to another questions (and make another tests) if any. Thanks to all.
dstogov
commented
1 month ago As you didn't have a consistent reproduction case, removal of xdebug might only hide the problem and it might appear back on some conditions. Also may be xdebug has to be fixed. Anyway, it's good you don't see crashes any more. Please reopen the issue if you'll see crashes again.
Description
I have site running under apache & php. One of apache process crashes in random moment of time a few times per hour. Apache log:
I took core dump and opened it in gdb.
As you see heap->free_slot[13] is an invalid pointer.
Backtrace:
zbacktrace:
php.ini:
The
opcache.protect_memorystring does not affect crashes.PHP Version
PHP 8.3.8
Operating System
CentOS Linux 7