PHP :: Bug #71560 :: segfault in zend_parse

Bug #71560

segfault in zend_parse_parameters

Submitted:

2016-02-09 12:52 UTC

Modified:

2020-04-11 14:11 UTC

Votes:	4
Avg. Score:	4.5 ± 0.5
Reproduced:	4 of 4 (100.0%)
Same Version:	2 (50.0%)
Same OS:	2 (50.0%)

From:

sautier dot louis at gmail dot com

Assigned:

cmb (profile)

Status:

Closed

Package:

FPM related

PHP Version:

7.0.3

OS:

Linux (Archlinux)

Private report:

CVE-ID:

None

View Developer Edit

[2016-02-09 12:52 UTC] sautier dot louis at gmail dot com

Description:
------------
Hi,
I regularly run into crashes since I updated to PHP 7. My setup is quite standard: nginx + PHP-FPM for a Wordpress site.
After running smoothly for a couple of days, the processes will start segfaulting.

I'm running Archlinux's php-7.0.3-1 whose configuration can be seen at https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/php
I have not yet been able to reliably reproduce the issue. All I know is that it happens after a few days and that a restart fixes it.

Expected result:
----------------
Feb 09 13:30:46 kim kernel: php-fpm[16015]: segfault at 10 ip 0000000000691729 sp 00007fffccc439f0 error 4 in php-fpm[400000+89b000]
Feb 09 13:30:46 kim nginx[566]: 2016/02/09 13:30:46 [error] 578#0: *145203 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: ******, server: website
Feb 09 13:30:47 kim systemd-coredump[16036]: Process 16015 (php-fpm) of user 33 dumped core.
                                             
                                             Stack trace of thread 16015:
                                             #0  0x0000000000691729 n/a (php-fpm)
                                             #1  0x0000000000691f0f n/a (php-fpm)
                                             #2  0x00000000006922a6 zend_parse_parameters (php-fpm)
                                             #3  0x00000000005dc82e n/a (php-fpm)
                                             #4  0x00000000006d94bd n/a (php-fpm)
                                             #5  0x00000000006ca58b execute_ex (php-fpm)
                                             #6  0x000000000071d797 zend_execute (php-fpm)
                                             #7  0x0000000000689503 zend_execute_scripts (php-fpm)
                                             #8  0x0000000000629ee0 php_execute_script (php-fpm)
                                             #9  0x0000000000433bc2 n/a (php-fpm)
                                             #10 0x00007f5640c10610 __libc_start_main (libc.so.6)
                                             #11 0x00000000004349f9 _start (php-fpm)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2016-02-09 13:37 UTC] laruence@php.net

are you using any extension that is not bundled with php-src?

[2016-02-09 13:40 UTC] sautier dot louis at gmail dot com

This is the outout of php -m:
[PHP Modules]
apc
apcu
bz2
Core
ctype
curl
date
dom
exif
fileinfo
filter
gd
gettext
hash
iconv
intl
json
libxml
mbstring
mcrypt
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
Phar
posix
readline
Reflection
session
SimpleXML
soap
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

[2016-02-09 15:29 UTC] laruence@php.net

then try with valgrind and set env ZEND_DONT_UNLOAD_MODULES=1

[2016-02-09 16:09 UTC] sautier dot louis at gmail dot com

I just tried but valgrind makes the site excruciatingly slow (> 10 seconds to load the front page). 
Is there anything else I could do?
I could try to recompile php with -g so we can see the n/a symbols?

[2016-02-10 02:40 UTC] laruence@php.net

yeah, that will be great, at least we should know which function trigger it

[2016-02-15 08:51 UTC] sautier dot louis at gmail dot com

Here is the backtrace with debugging symbols:
Feb 15 09:39:48 kim systemd-coredump[11137]: Process 11113 (php-fpm) of user 33 dumped core.
                                             
                                             Stack trace of thread 11113:
                                             #0  0x0000000000691729 zend_parse_arg_string (php-fpm)
                                             #1  0x0000000000691f0f zend_parse_va_args (php-fpm)
                                             #2  0x00000000006922a6 zend_parse_parameters (php-fpm)
                                             #3  0x00000000005dc82e zif_unserialize (php-fpm)
                                             #4  0x00000000006d94bd ZEND_DO_ICALL_SPEC_HANDLER (php-fpm)
                                             #5  0x00000000006ca58b execute_ex (php-fpm)
                                             #6  0x000000000071d797 zend_execute (php-fpm)
                                             #7  0x0000000000689503 zend_execute_scripts (php-fpm)
                                             #8  0x0000000000629ee0 php_execute_script (php-fpm)
                                             #9  0x0000000000433bc2 main (php-fpm)
                                             #10 0x00007f47e78da610 __libc_start_main (libc.so.6)
                                             #11 0x00000000004349f9 _start (php-fpm)

[2016-02-24 08:30 UTC] sautier dot louis at gmail dot com

Hi laruence,
Do you need more feedback or is this enough to help you track down the issue?

[2020-04-11 13:37 UTC] cmb@php.net

-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb

[2020-04-11 13:37 UTC] cmb@php.net

This is an issue with unserialize(); possibly, the string passed
to that function is corrupt.  Anyhow, does it still happen with
any of the actively supported PHP versions[1]?

[1] <https://www.php.net/supported-versions.php>

[2020-04-11 13:54 UTC] sautier dot louis at gmail dot com

-Status: Feedback +Status: Assigned

[2020-04-11 13:54 UTC] sautier dot louis at gmail dot com

I don't think it does. Wordpress has been updated quite a few times since so it might even have removed the code that triggered the crash.

[2020-04-11 14:11 UTC] cmb@php.net

-Status: Assigned +Status: Closed

[2020-04-11 14:11 UTC] cmb@php.net

Thanks for the fast reply!  Another possible reason why that
segfault doesn't occur anymore might be that the problem has been
resolved in PHP.

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2025 The PHP Group All rights reserved.	Last updated: Sun Oct 26 20:00:01 2025 UTC