Some ideas about the SIGSEGV error of php-cgi

Several machines using nginx + php-fpm can occasionally see such content in the php-fpm.log reference Oct2823: 13: 53.849419 [NOTICE] fpm_got_signal (), line73: receivedSIGCHLDOct2823: 13: 53.849490 [WARNING] fpm_children_bury (several machines using nginx + php-fpm occasionally see this in the php-fpm.log)

Reference
Oct 28 23:13:53. 849419 [NOTICE] fpm_got_signal (), line 73: received SIGCHLD
Oct 28 23:13:53. 849490 [WARNING] fpm_children_bury (), line 229: child 15044 (pool default) exited on signal 11 SIGSEGV after 1.332818 seconds
Oct 28 23:13:53. 850341 [NOTICE] fpm_children_make (), line 305: child 15122 (pool default) started

If there are many processes that receive the SIGSEGV signal, you can see the following logs:

Reference
Oct 28 09:03:15. 812009 [WARNING] fpm_children_bury (), line 256: failed PRocesses threshold (10 in 60 sec) is reached, initiating reload
Oct 28 09:03:15. 812030 [NOTICE] fpm_pctl (), line 208: switching to 'reloading' state

Then php-fpm will restart. The
Failed processes threshold (10 in 60 sec) is reached
It is set in the php-fpm.conf to indicate that if the number of php-cgi processes with SIGSEGV or SIGBUS errors exceeds 10 in 60 seconds, php-fpm will restart. You can increase the threshold for this restart by setting the value of emergency_restart_threshold in the php-fpm.conf, such as increasing to 60, which can avoid php-fpm restart in some cases, however, this is not the fundamental solution to the problem.

SIGSEGV signal

Reference
SIGSEGV --- Segment Fault. The possible cases of your encountering this error are:
1. buffer overflow --- usually caused by a pointer reference out of range.
2. stack overflow --- please keep in mind that the default stack size is 8192 K.
3. illegal file access --- file Operations are forbidden on our judge system

Article 3 has a great relationship with this issue. That is, php-cgi accesses a non-existent or unauthorized file.
The php-fpm patch I used is in version 0.5.8. for some reasons, you only need to set

Reference
Fastcgi_param SCRipT_NAME $ fastcgi_script_name;

If php-cgi cannot find the file or has No Access permission, the system will prompt No input file specified. or Access denied.
The problem seems to be deadlocked again.
Later, a cgi. fix_pathinfo parameter of php-cgi was found in php. ini.

Reference
Cgi. fix_pathinfo boolean
CGI is supported by true PATH_INFO/PATH_TRANSLATED. In the past, PHP set PATH_TRANSLATED to SCRIPT_FILENAME, regardless of what PATH_INFO is. For more information about PATH_INFO, see cgi specifications. Setting this value to 1 will make php cgi correct its path to conform to the specification. Setting 0 will make PHP behave the same way as before. The default value is zero. You should correct the script to use SCRIPT_FILENAME instead of PATH_TRANSLATED.

Set the value of this parameter to 1. cgi will perform more checks to determine the request path, which part is the file name and which part is the path name.
The following is a line on google groups.

Reference
When cgi. fix_pathinfo was set to "1" it caused a lot of checks in order to find which part of SCRIPT_FILENAME is a file name and which is PATH_INFO. in case of missing file it caused NULL
In path_translated, which caused the crash.

This problem has consumed too much energy and I am not willing to spend more time investigating the problem. For example, you can use gbd to view dump files generated after a php-cgi error. However, this problem occurs only occasionally and is hard to be captured. If a brother has encountered this problem, or you have a better solution, you may wish to discuss it.
After modifying this parameter, we observe that the SIGSEGV error does disappear on some servers.
I would like to add that from half past six to 09:26 on April 9, November 10, there were a large number of SIGSEGV errors on the three servers (apps for the internal network of the school) and faults on the internal servers, I generated a lot of incorrect post/logs on these servers. later I asked the engineers in the school that they only said that the service was down, but they refused to give a detailed explanation of the situation. After that, I simulated the post. Is there a problem ?? Strange