php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73381 SIGSEGV related to php_pcre
Submitted: 2016-10-24 10:58 UTC Modified: 2019-03-31 04:22 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: lsn at nuvopoint dot com Assigned:
Status: No Feedback Package: PCRE related
PHP Version: 7.0.12 OS: Ubuntu 16.04.1 LTS
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2016-10-24 10:58 UTC] lsn at nuvopoint dot com
Description:
------------
FPM makes a coredump, which is captured to /var/crash.

The coredump file can be found here: https://cloud.nuvoweb.dk/_usr_sbin_php-fpm7.0.33.crash

I've just started debugging this, and I have zero experience reading these crash files, so I can't report much.

What I can tell is that its running on Ubuntu 16 with all the latest upgrades (as of today), on Nginx 1.11.5. No errors in any logs, be it syslog, nginx-error.log, php's log. The only hint is an error in php-fpm:

[24-Oct-2016 09:44:03] NOTICE: fpm is running, pid 1057
[24-Oct-2016 09:44:03] NOTICE: ready to handle connections
[24-Oct-2016 09:44:03] NOTICE: systemd monitor interval set to 10000ms
[24-Oct-2016 10:06:04] WARNING: [pool www] child 1371 exited on signal 11 (SIGSEGV - core dumped) after 1321.212667 seconds from start

I can reproduce it on our setup, using Postman, but if we could decode the crash log above, that might reveal if that is even necessary.

I'm available to debug this if needed.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-11-09 09:14 UTC] lsn at nuvopoint dot com
Managed to decode some of the crash file:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fd5839b16a6 in pcre_exec () from /lib/x86_64-linux-gnu/libpcre.so.3
 [2016-11-09 09:22 UTC] lsn at nuvopoint dot com
Figured out how to do a backtrace, don't know if that is helpful:
#1  0x000055c2800df76c in php_pcre_replace_impl ()
#2  0x000055c2800e058e in php_pcre_replace ()
#3  0x000055c2800e0646 in ?? ()
#4  0x000055c2800e0a22 in ?? ()
#5  0x000055c2800e16fc in ?? ()
#6  0x000055c2802073da in dtrace_execute_internal ()
#7  0x000055c28029c540 in ?? ()
#8  0x000055c280257a4b in execute_ex ()
#9  0x000055c280207271 in dtrace_execute_ex ()
#10 0x000055c28029c67d in ?? ()
#11 0x000055c280257a4b in execute_ex ()
#12 0x000055c280207271 in dtrace_execute_ex ()
#13 0x000055c28029c67d in ?? ()
#14 0x000055c280257a4b in execute_ex ()
#15 0x000055c280207271 in dtrace_execute_ex ()
#16 0x000055c28029c67d in ?? ()
#17 0x000055c280257a4b in execute_ex ()
#18 0x000055c280207271 in dtrace_execute_ex ()

Then it just loops like that, I stopped looking when it passed #10000.
 [2016-11-09 09:33 UTC] lsn at nuvopoint dot com
-Summary: Mysterious fpm coredump +Summary: SIGSEGV related to php_pcre -Package: FPM related +Package: PCRE related
 [2016-11-09 09:33 UTC] lsn at nuvopoint dot com
Changed package to PCRE
 [2019-03-18 16:48 UTC] nikic@php.net
-Status: Open +Status: Feedback
 [2019-03-18 16:48 UTC] nikic@php.net
> Then it just loops like that, I stopped looking when it passed #10000.

This looks like it might just be a stack overflow that happened to fall into PCRE code.

As this bug is a bit dated, is this something you still experience? If so, using "ulimit -s" to increase the stack size might be a quick way to check if that's the issue.
 [2019-03-31 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug 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 and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Thu May 23 14:01:34 2019 UTC