PHP: Segfault at « some memory address » error 6 in libpcre.so.1.2.1
Nginx FastCGI configuration was good, the file permissions all good and PHP-FPM was running fine. Yet loading the web page would only give me "file not found". Really?
The file was there, I could see it on the system. Nginx log wouldn't indicate much; with the access log just complaining about a HTTP 404 and the error log printing "Primary script unknown".
==> access.log <== 172.16.0.1 - - [21/Sep/2016:11:13:55 +0200] "GET /index.php HTTP/1.1" 404 47 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10116) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
==> error.log <== 2016/09/21 11:14:21 [error] 9659#9659: *13 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 172.16.0.1, server: 127.0.0.1, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "127.0.0.1"
Then, this particular line in the journal log paints a new picture.
php: segfault at 7ffee1bf5ea0 ip 00007f4d150c59f7 sp 00007ffee1bf5e90 error 6 in libpcre.so.1.2.1
Indeed, the issue wasn't with the Nginx FastCGI parameters or file permission.
The libpcre.so.1.2.1 library provides functions that are used by PHP PCRE (Perl-Compatible Regular Expressions). It's not surprising that pattern matching through regular expressions could hit on the system resources. Therefore, for the small Virtual Machine (512M RAM) on which I was configuring the application, I had to adjust the PCRE limits.
In this case, I had to tinker with the pcre.backtracklimit and pcre.recursionlimit directives in the php.ini config file. Remember that if you're running php-fpm, then you'll need to edit the config file within the fpm folder (e.g /etc/php5/fpm/php.ini).
The default values are 1000000 and 100000 for pcre.backtracklimit and pcre.recursionlimit respectively in PHP 5. Adjusting (lowering) those values as per your operating system's stack limits (ulimit -s) and available memory would end the pattern search earlier; thus not hitting the stack limit.
Oh yeah, sure, do inform your fellow developers about regular expressions that are costly when you're experimenting on small virtual machines.