Open drsheep404 opened 1 month ago
Some questions:
opcache.protect_memory=1
in your php.ini?The addresses are not meaningful on their own because of ASLR and the fact that binaries between systems can differ. Ideally we get a backtrace from gdb.
Same problem here!
We are already opened a issue at plesk forum. PHP8.0 doesn't have this problem. https://talk.plesk.com/threads/segfault-error-4-in-php-fpm-likely-on-cpu-4.374374/#post-947178
- Are you using Opcache JIT?
tested with and without. Same problem
- Does the issue reproduce when disabling Opcache?
Yes. We disabled opcache and had the same error
- Does it crash randomly or reliably?
Randomly. If you fast reload the webpage, then sometimes 503 or 500 appears. I created a crawler and at the first 5 minutes no errors but than randomly 2 or three subpages per Minute
- Does it consistently crash if you set the debugging option
opcache.protect_memory=1
in your php.ini?
I will test :)
- Can you please share your fpm configuration?
Thats the inital Settings from plesk. I tested Debian11, Debian12 and Ubuntu24 with inital installation from Plesk. The problem occours through all. I will share my config.
- Does it consistently crash if you set the debugging option
opcache.protect_memory=1
in your php.ini?
Yes...
Thanks for the info!
The fact it reliably reproduces with protect_memory
is an indication that the opcache shm gets corrupted.
Can you please either use valgrind or gdb to get a backtrace? To do so, you can start php-fpm in foreground mode like so:
For Valgrind: valgrind php-fpm -F
or if you want to use gdb: gdb --args php-fpm -F
and for gdb enter set follow-fork-mode child
and then enter continue
. When gdb captures the crash you can use bt full
to get the full backtrace.
You may need to install the debug symbols package for php on your distro to get a meaningful backtrace.
Alternatively, we can also debug it for you but would need access to the source code in that case.
I hope this helps?
(gdb) bt full
#0 0x00007fc9d432960f in __libc_accept (fd=14, addr=..., len=0x7ffc84e1e5f8) at ../sysdeps/unix/sysv/linux/accept.c:26
sc_ret = -512
sc_cancel_oldtype = 0
sc_ret = <optimized out>
#1 0x0000559f2efbe13f in ?? ()
No symbol table info available.
#2 0x0000559f2ec5f709 in ?? ()
No symbol table info available.
Backtrace stopped: Cannot access memory at address 0x7ffc84e1ec18
(gdb)
Looks like only the main thread got backtraced. Try thread apply all bt full
instead of bt full
.
I also see that the debug symbols may not be available, depending on your distro it can be auto-downloaded. E.g. for Debian it's probably sufficient to set export DEBUGINFOD_URLS="https://debuginfod.debian.net"
in your terminal.
Can I also do it with gdb --pid <Master-Process>
?
You can do it with --pid
but you'll have to get the pid of the child/worker process instead of the master.
Hahaaaa get it
(gdb) thread apply all bt full
Thread 1 (Thread 0x7fc20dd5d480 (LWP 15720) "php-fpm"):
#0 0x0000555e676702e7 in execute_ex ()
No symbol table info available.
#1 0x0000555e675f105a in zend_call_function ()
No symbol table info available.
#2 0x0000555e6744fa29 in ?? ()
No symbol table info available.
#3 0x0000555e67450e08 in ?? ()
No symbol table info available.
#4 0x0000555e67450ea3 in ?? ()
No symbol table info available.
#5 0x0000555e674512f2 in ?? ()
No symbol table info available.
#6 0x0000555e6766f0ad in execute_ex ()
No symbol table info available.
#7 0x0000555e67674125 in zend_execute ()
No symbol table info available.
#8 0x0000555e675ffea8 in zend_execute_scripts ()
No symbol table info available.
#9 0x0000555e675945be in php_execute_script ()
No symbol table info available.
#10 0x0000555e6738ec5a in ?? ()
No symbol table info available.
#11 0x00007fc20e22724a in __libc_start_call_main (main=main@entry=0x555e6738def0, argc=argc@entry=2, argv=argv@entry=0x7ffdfe5d84f8) at ../sysdeps/nptl/libc_start_call_main.h:58
self = <optimized out>
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140728870995192, 1643806115081770837, 0, 140728870995216, 93863951880344, 140471449374752, -1642683253192894635, -1635962564098631851}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7ffdfe5d84f8, 0x7ffdfe5d84f8}, data = {prev = 0x0, cleanup = 0x0, canceltype = -27425544}}}
not_first_call = <optimized out>
#12 0x00007fc20e227305 in __libc_start_main_impl (main=0x555e6738def0, argc=2, argv=0x7ffdfe5d84f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdfe5d84e8) at ../csu/libc-start.c:360
No locals.
#13 0x0000555e67390c11 in _start ()
No symbol table info available.
Alright, so now we know it happens in your code somewhere in a callback. What distro are you on? You'll have to get the debug symbols package such that we can read where exactly it crashes.
Debian 12.5
Not a distro I use so I can't check, but apparently they ship their debug symbols in the package php8.2-fpm-dbgsym
for fpm.
#0 0x00007f8b7e717240 in __GI___libc_write (fd=5, buf=buf@entry=0x7f8b743c1ec0, nbytes=nbytes@entry=28984) at ../sysdeps/unix/sysv/linux/write.c:26
sc_ret = -32
__arg3 = <optimized out>
_a2 = <optimized out>
sc_ret = <optimized out>
sc_ret = <optimized out>
__arg1 = <optimized out>
_a3 = <optimized out>
sc_cancel_oldtype = <optimized out>
resultvar = <optimized out>
__arg2 = <optimized out>
_a1 = <optimized out>
#1 0x0000562056348289 in safe_write (count=65528, buf=0x7f8b743b9000, req=0x562057a21310) at ./main/fastcgi.c:943
ret = <optimized out>
n = 36544
ret = <optimized out>
n = <optimized out>
#2 fcgi_write (req=0x562057a21310, type=type@entry=FCGI_STDOUT,
str=str@entry=0x7f8b74389018 "<!DOCTYPE html>\n<html lang=\"de-DE\">\n<head>\n\t<meta charset=\"UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n\t<link rel=\"pingback\" href=\"https://www.xmlrpc.php\" />\n\n\t<scr"..., len=len@entry=273303) at ./main/fastcgi.c:1631
pos = 196584
pad = <optimized out>
limit = <optimized out>
rest = <optimized out>
#3 0x00005620563512f9 in sapi_cgibin_single_write (str_length=273303,
str=0x7f8b74389018 "<!DOCTYPE html>\n<html lang=\"de-DE\">\n<head>\n\t<meta charset=\"UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n\t<link rel=\"pingback\" href=\"https://www./xmlrpc.php\" />\n\n\t<scr"...) at ./sapi/fpm/fpm/fpm_main.c:249
request = <optimized out>
ret = <optimized out>
ret = <optimized out>
request = <optimized out>
#4 sapi_cgibin_ub_write (str=<optimized out>, str_length=273303) at ./sapi/fpm/fpm/fpm_main.c:276
ptr = 0x7f8b74389018 "<!DOCTYPE html>\n<html lang=\"de-DE\">\n<head>\n\t<meta charset=\"UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n\t<link rel=\"pingback\" href=\"https://www./xmlrpc.php\" />\n\n\t<scr"...
remaining = 273303
ret = <optimized out>
#5 0x0000562056201f30 in php_output_op (op=op@entry=0, str=<optimized out>, len=len@entry=273303) at ./main/output.c:1071
context = {op = 0, in = {data = 0x0, size = 0, used = 0, free = 0, _reserved = 0}, out = {
data = 0x7f8b74389018 "<!DOCTYPE html>\n<html lang=\"de-DE\">\n<head>\n\t<meta charset=\"UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge\">\n\t<link rel=\"pingback\" href=\"https://www./xmlrpc.php\" />\n\n\t<scr"..., size = 0, used = 273303, free = 0, _reserved = 0}}
active = <optimized out>
obh_cnt = <optimized out>
#6 0x0000562056202055 in php_output_op (len=273303, str=<optimized out>, op=0) at ./main/output.c:1037
context = <optimized out>
active = <optimized out>
obh_cnt = <optimized out>
#7 php_output_write (str=<optimized out>, len=273303) at ./main/output.c:241
No locals.
#8 0x0000562056284c9d in ZEND_ECHO_SPEC_TMPVAR_HANDLER () at ./Zend/zend_vm_execute.h:14477
str = <optimized out>
z = <optimized out>
#9 0x00005620562c73d3 in execute_ex (ex=0x5) at ./Zend/zend_vm_execute.h:58685
vm_stack_data = {orig_opline = 0x56204e73a258, orig_execute_data = 0x7f8b7be131f0, hybrid_jit_red_zone = "\000\000\000\000\000\000\000\000{\271/V V\000"}
#10 0x0000562056075c40 in ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER () at ./Zend/zend_vm_execute.h:2052
call = 0x7f8b7be132e0
fbc = <optimized out>
ret = <optimized out>
#11 0x0000562056076b0e in execute_ex (ex=0x5) at ./Zend/zend_vm_execute.h:57256
vm_stack_data = {orig_opline = 0x56204e73aaa0, orig_execute_data = 0x7f8b7be13170, hybrid_jit_red_zone = "\3601\341{\213\177\000\000{\271/V V\000"}
#12 0x0000562056075c40 in ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER () at ./Zend/zend_vm_execute.h:2052
call = 0x7f8b7be131f0
fbc = <optimized out>
ret = <optimized out>
#13 0x0000562056076b0e in execute_ex (ex=0x5) at ./Zend/zend_vm_execute.h:57256
vm_stack_data = {orig_opline = 0x56204e72c1d8, orig_execute_data = 0x7f8b7be13080, hybrid_jit_red_zone = "p1\341{\213\177\000\000{\271/V V\000"}
#14 0x0000562056075c40 in ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER () at ./Zend/zend_vm_execute.h:2052
call = 0x7f8b7be13170
fbc = <optimized out>
ret = <optimized out>
#15 0x0000562056076b0e in execute_ex (ex=0x5) at ./Zend/zend_vm_execute.h:57256
vm_stack_data = {orig_opline = 0x56204e6ef328, orig_execute_data = 0x7f8b7be13020, hybrid_jit_red_zone = "\2000\341{\213\177\000\000{\271/V V\000"}
#16 0x0000562056075c40 in ZEND_DO_FCALL_SPEC_OBSERVER_HANDLER () at ./Zend/zend_vm_execute.h:2052
--Type <RET> for more, q to quit, c to continue without paging--
call = 0x7f8b7be13080
fbc = <optimized out>
ret = <optimized out>
#17 0x0000562056076b0e in execute_ex (ex=0x5) at ./Zend/zend_vm_execute.h:57256
vm_stack_data = {orig_opline = 0x0, orig_execute_data = 0x5620564effc0 <executor_globals>, hybrid_jit_red_zone = "\000\000\000\000\000\000\000\000{\271/V V\000"}
#18 0x000056205624d13a in zend_call_function (fci=<optimized out>, fci_cache=<optimized out>) at ./Zend/zend_execute_API.c:957
orig_jit_trace_num = 0
i = <optimized out>
call = 0x7f8b7be13020
fci_cache_local = {function_handler = 0x5620564efa00 <sapi_globals>, calling_scope = 0x0, called_scope = 0x562057a2547d, object = 0x562056084365 <zm_deactivate_date+21>, closure = 0x5620564efa00 <sapi_globals>}
func = <optimized out>
call_info = <optimized out>
object_or_called_scope = <optimized out>
orig_fake_scope = 0x0
#19 0x00005620561802b8 in user_shutdown_function_call (zv=<optimized out>) at ./ext/standard/basic_functions.c:1632
shutdown_function_entry = <optimized out>
retval = {value = {lval = 140722506686416, dval = 6.9526156150423256e-310, counted = 0x7ffc8305dfd0, str = 0x7ffc8305dfd0, arr = 0x7ffc8305dfd0, obj = 0x7ffc8305dfd0, res = 0x7ffc8305dfd0, ref = 0x7ffc8305dfd0, ast = 0x7ffc8305dfd0,
zv = 0x7ffc8305dfd0, ptr = 0x7ffc8305dfd0, ce = 0x7ffc8305dfd0, func = 0x7ffc8305dfd0, ww = {w1 = 2198200272, w2 = 32764}}, u1 = {type_info = 0, v = {type = 0 '\000', type_flags = 0 '\000', u = {extra = 0}}}, u2 = {
next = 1235517999, cache_slot = 1235517999, opline_num = 1235517999, lineno = 1235517999, num_args = 1235517999, fe_pos = 1235517999, fe_iter_idx = 1235517999, guard = 1235517999, constant_flags = 1235517999, extra = 1235517999}}
call_status = SUCCESS
#20 0x000056205626eedc in zend_hash_apply (ht=0x7f8b7bed6310, apply_func=apply_func@entry=0x562056180290 <user_shutdown_function_call>) at ./Zend/zend_hash.c:2071
zv = 0x7f8b7be8e158
idx = 1
result = <optimized out>
#21 0x00005620561863e6 in php_call_shutdown_functions () at ./ext/standard/basic_functions.c:1693
__orig_bailout = 0x7ffc83061c60
__bailout = {{__jmpbuf = {94696886958592, 137760716150328427, 94696909198106, 94696885740521, 60, 0, -139494318325576597, -5932999288151421845}, __mask_was_saved = 0, __saved_mask = {__val = {835349890, 94696909181712, 15,
140237055459392, 140237060221672, 1, 0, 140722506700496, 94696884063202, 1, 140722506700496, 1, 94696886958592, 0, 94696909198106, 94696885740521}}}}
#22 0x00005620561ef395 in php_request_shutdown (dummy=dummy@entry=0x0) at ./main/main.c:1854
report_memleaks = true
#23 0x0000562056082295 in main (argc=<optimized out>, argv=<optimized out>) at ./sapi/fpm/fpm/fpm_main.c:1970
primary_script = <optimized out>
__orig_bailout = <optimized out>
__bailout = {{__jmpbuf = {12, 137760716150852715, 0, 94696886810880, 94696886986776, 0, -139494318573040533, -5932999154497958805}, __mask_was_saved = 0, __saved_mask = {__val = {140237059737312, 140722506702912, 140237059692824, 0,
140237104939008, 13, 140237099438488, 140722506702912, 94696886273816, 140237110726688, 140237110587070, 1, 0, 140237110524024, 140237110614320, 140237059692736}}}}
exit_status = 0
cgi = 0
c = <optimized out>
use_extended_info = 0
file_handle = {handle = {fp = 0x0, stream = {handle = 0x0, isatty = 0, reader = 0x0, fsizer = 0x0, closer = 0x0}}, filename = 0x0, opened_path = 0x0, type = 0 '\000', primary_script = true, in_list = false, buf = 0x0, len = 0}
orig_optind = 1
orig_optarg = 0x0
ini_builder = {value = 0x0, length = 0}
max_requests = 0
requests = <optimized out>
fcgi_fd = <optimized out>
request = 0x562057a21310
fpm_config = <optimized out>
fpm_prefix = 0x0
fpm_pid = 0x0
test_conf = 0
force_daemon = <optimized out>
force_stderr = 0
php_information = 0
php_allow_to_run_as_root = 0
__func__ = "main"
ret = <optimized out>
__orig_bailout = <optimized out>
__bailout = <optimized out>
__str = <optimized out>
Thanks, seems like the debug symbols are now present!
It seems strange that this is the point it crashes because this is during shutdown and during writing the final response.
You're still testing with opcache.protect_memory=1
right? And you're waiting for a crash before creating the backtrace?
Ah no I'm testing without opcache.protect_memory=1
I will test with opcache.protect_memory=1
Thats really strange - no errors in the last 30 minutes....opcache.protect_memory=1 seems to do the job...Last time this changed nothing :O
-- Edit - i wrote too fast xD
Hi,
only as notice, my php.ini conf was only edited with:
opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=256 opcache.interned_strings_buffer=32 opcache.max_accelerated_files=30000 opcache.max_wasted_percentage=10 opcache.use_cwd=1 opcache.revalidate_freq=90 opcache.revalidate_path=1 opcache.enable_file_override=1
I saw that this seqfault started at 14th May (and here is the point, I updated from .18 to .19 at this day, but I'm not fully sure if it also affect older versions, because logs started from 12th May (without seqfault)). And I use only PHP8.2, so I can't confirm it's also in 8.0 and 8.1 (or 8.3). Sometimes I also notice a seqfault at "7f1757e786d0":
@alex0107 Do you use the deb.sury.org packages? Because we do.
I started a discussion (https://github.com/oerdnj/deb.sury.org/discussions/2135) to be sure. Maybe the issue is related to the package-bundle from sury?
Yes and plesk-xxx-fpm
So a new bt - I hope this time it helps more....
Okay this is a realistic stacktrace for a crash bug. It appears to be a memory corruption bug, and the problem with those is that the point where it crashes is unlikely to be the point where it actually went wrong initially.
I'm afraid you'll need to run php-fpm under Valgrind in foreground mode, and preferably with the environment variable USE_ZEND_ALLOC=0
set.
I'm assuming your code is closed-source? If it's open, then we can try using debugging techniques on our own systems.
Could you also try disabling observers? So we know whether they are related. You're likely using some extension that enables them (e.g. Datadog, or possibly others).
Or is this a problem with the package deb.sury.org and plesk-php8x-fpm? Do we have to contact them?
I'm assuming your code is closed-source? If it's open, then we can try using debugging techniques on our own systems.
I can send you the code. The problems occours on multiple WordPress websites of our costumers. How can I send you the files? Please not directly through a public github issue ;)
Or is this a problem with the package deb.sury.org and plesk-php8x-fpm? Do we have to contact them?
I don't think the problem is in the packaging.
I'm assuming your code is closed-source? If it's open, then we can try using debugging techniques on our own systems.
I can send you the code. The problems occours on multiple WordPress websites of our costumers. How can I send you the files? Please not directly through a public github issue ;)
The thing is thought that since I'm not employed by anyone to work on PHP, I don't have any legal protection for the "just in case" situation when dealing with private data. Not sure how this is for people employed by the PHP foundation though.
So I think there isn‘t any private data on this website. Do you have a email or discord or something else so I can send you the file? 😄
@alex0107 Can you also post a list of extensions that are enabled? Since you're using observers, it's also possible that some third party extension contributes to the problem.
Yes for sure - I don't find any observers like monit or something like this. The extension list:
Thats really strange - today the server hangs an i trying to restart. Than following error occours:
Do you have a conclusion? :)
Usually happens when a process is stuck or not responding for an extended period of time. In your case, it seems to involve php-fpm and pgrep tasks.
You can check if there is something fishy: journalctl -u php-fpm8.2
--> Or better: dmesg | grep php-fpm
There you see what's going on.
In my case, still: ... [837330.002891] php-fpm8.2[2119454]: segfault at 7fc2030826d0 ip 000055c0ae489ebd sp 00007ffc9acb7cc0 error 4 in php-fpm8.2[55c0ae26a000+309000] likely on CPU 10 (core 10, socket 0) [837334.074696] php-fpm8.2[78015]: segfault at 7fc203069110 ip 000055c0ae489ebd sp 00007ffc9acb7cc0 error 4 in php-fpm8.2[55c0ae26a000+309000] likely on CPU 8 (core 8, socket 0) [837373.891710] php-fpm8.2[3913966]: segfault at 7fc203069110 ip 000055c0ae489ebd sp 00007ffc9acb7cc0 error 4 in php-fpm8.2[55c0ae26a000+309000] likely on CPU 1 (core 1, socket 0) [837404.411692] php-fpm8.2[3937033]: segfault at 7fc203841110 ip 000055c0ae489ebd sp 00007ffc9acb7cc0 error 4 in php-fpm8.2[55c0ae26a000+309000] likely on CPU 9 (core 9, socket 0) ....
Yes but why is php-fpm stuck? :D
There are no errors (except the segfaults...)
... [ 890.960699] php-fpm[10517]: segfault at 56214e719b78 ip 00005621532aec94 sp 00007ffd37fc57a0 error 7 in php-fpm[562152f8f000+3b5000] likely on CPU 12 (core 12, socket 0) [ 911.420068] php-fpm[10511]: segfault at 664ccc23 ip 000056215328b176 sp 00007ffd37fc5740 error 6 in php-fpm[562152f8f000+3b5000] likely on CPU 13 (core 13, socket 0) [ 1230.839886] php-fpm[11000]: segfault at 56214b42d168 ip 00005621532aec37 sp 00007ffd37fc57a0 error 7 in php-fpm[562152f8f000+3b5000] likely on CPU 15 (core 15, socket 0) [ 1306.948549] php-fpm[11048]: segfault at 56214b4b9678 ip 00005621532b02b2 sp 00007ffd37fc57a0 error 7 in php-fpm[562152f8f000+3b5000] likely on CPU 15 (core 15, socket 0) [ 1525.808950] php-fpm[11459]: segfault at 0 ip 000056215328b176 sp 00007ffd37fc4d60 error 6 in php-fpm[562152f8f000+3b5000] likely on CPU 15 (core 15, socket 0) [ 1527.137602] php-fpm[11466]: segfault at 56214b0928e8 ip 0000562153285add sp 00007ffd37fc5710 error 7 in php-fpm[562152f8f000+3b5000] likely on CPU 0 (core 0, socket 0) [ 1800.348770] php-fpm[11562]: segfault at 2 ip 00005621532aec37 sp 00007ffd37fc57a0 error 6 in php-fpm[562152f8f000+3b5000] likely on CPU 14 (core 14, socket 0) ...
What do you mean by "stuck". If there's a crash, FPM should just create a new child. Is that not what is happening?
Is this happening only in high traffic (meaning occasionally just for some request) or are you able to reliably to recreate it locally as well or on some non prod environment? If you are able to recreate locally / on non prod environment (even with something like wrk), then running that under valgrind as suggested could show what the problem is.
No I've created a crawler and the error happens completey random
No feedback was provided. The issue 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. Thank you.
Description
Hi,
sorry for unclear report, I don't know why this happens:
kernel: [269065.088395] php-fpm8.2[2107797]: segfault at 7f377e872428 ip 0000562b0b8d9ebd sp 00007ffcd580fec0 error 4 in php-fpm8.2[562b0b6ba000+309000] likely on CPU 3 (core 3, socket 0) kernel: [269065.088412] Code: 74 7b 48 c1 e3 05 4c 01 e3 48 3b 6b 18 75 36 48 89 d8 5b 5d 41 5c c3 66 0f 1f 44 00 00 48 8b 7b 18 48 85 ff 74 0a 48 8b 45 10 <48> 39 47 10 74 3d 8b 5b 0c 83 fb ff 74 45 48 c1 e3 05 4c 01 e3 48 kernel: [269068.671543] php-fpm8.2[1753950]: segfault at 7f377e86e6d0 ip 0000562b0b8d9ebd sp 00007ffcd580fe50 error 4 in php-fpm8.2[562b0b6ba000+309000] likely on CPU 7 (core 7, socket 0) kernel: [269068.671602] Code: 74 7b 48 c1 e3 05 4c 01 e3 48 3b 6b 18 75 36 48 89 d8 5b 5d 41 5c c3 66 0f 1f 44 00 00 48 8b 7b 18 48 85 ff 74 0a 48 8b 45 10 <48> 39 47 10 74 3d 8b 5b 0c 83 fb ff 74 45 48 c1 e3 05 4c 01 e3 48 kernel: [269069.612500] php-fpm8.2[2108620]: segfault at 7f377e874428 ip 0000562b0b8d9ebd sp 00007ffcd580fec0 error 4 in php-fpm8.2[562b0b6ba000+309000] likely on CPU 8 (core 8, socket 0) kernel: [269069.612515] Code: 74 7b 48 c1 e3 05 4c 01 e3 48 3b 6b 18 75 36 48 89 d8 5b 5d 41 5c c3 66 0f 1f 44 00 00 48 8b 7b 18 48 85 ff 74 0a 48 8b 45 10 <48> 39 47 10 74 3d 8b 5b 0c 83 fb ff 74 45 48 c1 e3 05 4c 01 e3 48 kernel: [269073.181863] php-fpm8.2[1725486]: segfault at 7f377e074428 ip 0000562b0b8d9ebd sp 00007ffcd580fec0 error 4 in php-fpm8.2[562b0b6ba000+309000] likely on CPU 11 (core 11, socket 0) kernel: [269073.181878] Code: 74 7b 48 c1 e3 05 4c 01 e3 48 3b 6b 18 75 36 48 89 d8 5b 5d 41 5c c3 66 0f 1f 44 00 00 48 8b 7b 18 48 85 ff 74 0a 48 8b 45 10 <48> 39 47 10 74 3d 8b 5b 0c 83 fb ff 74 45 48 c1 e3 05 4c 01 e3 48
Someone has an idea? Using PHP8.2-fpm via nginx. This isn't an OOM-Killer, system is well balanced, but with very high traffic. Also all settings are optimized and correct, including opcache.
How I can find out which file or what causes the segfault? How I can better routing to point the issue (if possible?). I see the most segfault at 7f377e074428 only. But don't find any similar case about this.
Thanks! :)
PHP Version
PHP 8.2.19
Operating System
Debian 12 (bookworm)