php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #71269 php-fpm dumped core
Submitted: 2016-01-03 18:46 UTC Modified: 2016-03-04 13:10 UTC
Votes:15
Avg. Score:4.6 ± 0.7
Reproduced:15 of 15 (100.0%)
Same Version:14 (93.3%)
Same OS:15 (100.0%)
From: franck dot charras at openmailbox dot org Assigned: maarten (profile)
Status: Closed Package: FPM related
PHP Version: 7.0.1 OS: arch linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: franck dot charras at openmailbox dot org
New email:
PHP Version: OS:

 

 [2016-01-03 18:46 UTC] franck dot charras at openmailbox dot org 
Description:
------------
I have an install of owncloud 8.2 from two weeks ago, on arch linux. I upgraded to php 7, every things looks okay, except php-fpm crashing with the following log:

systemd-coredump[20086]: Process 19893 (php-fpm) of user 33 dumped core.
Stack trace of thread 19893:
#0 0x00007f95434f75f8 raise (libc.so.6)
#1 0x00000000006b4af5 n/a (php-fpm)
#2 0x00000000006b4bf2 n/a (php-fpm)
#3 0x00007f95434f7680 __restore_rt (libc.so.6)
#4 0x00007f95435ade0d accept (libc.so.6)
#5 0x00000000007201e0 n/a (php-fpm)
#6 0x000000000043367b n/a (php-fpm)
#7 0x00007f95434e4610 __libc_start_main (libc.so.6)
#8 0x0000000000434949 _start (php-fpm)
There aren't other owncloud logs.
It didn't crash before moving to php7 and I think i've followed all the instructions correctly.
The owncloud server still works but pages aren't refreshing immediately after performing actions, even if the actions are successfully processed (uploading, sharing, enabling, etc..).

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-01-04 11:39 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2016-01-04 11:39 UTC] laruence@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.
 [2016-01-04 14:09 UTC] franck dot charras at openmailbox dot org
-Status: Feedback +Status: Open
 [2016-01-04 14:09 UTC] franck dot charras at openmailbox dot org 
Unfortunately I don't know what script causes this crash. I only know that it's part of owncloud php website, and it's related to serving pages after modifying the database. Apart from that I'm a newbie user and i'm not that aware of PHP :-/ i'd be glad to help to provide more informations if you have particular request though. Maybe another user/developper will encounter the same bug and provide a more accurate bug report.
 [2016-01-07 12:23 UTC] franck dot charras at openmailbox dot org 
Hi, this morning i've gone again through all the settings for nginx/owncloud/php/php-fpm.

It seems that php-fpm has stopped crashing repeatedly.

It only stopped after I have it using 127.0.0.1:9000 instead of php-fpm.sock.

If I switch back it fills my logs with dumped core again.

Hope this can help,

Sincerely.
 [2016-01-08 18:17 UTC] mickael9 at gmail dot com 
Here's a (hopefully) more useful backtrace with PHP compiled in debug :

#0  0x00007f282b5f95f8 in raise () from /usr/lib/libc.so.6
#1  0x000000000083dc8b in zend_signal_handler (signo=3, siginfo=0x7ffc1f34ca70, context=0x7ffc1f34c940) at /home/mickael/php/src/php-7.0.2/Zend/zend_signal.c:178
#2  0x000000000083d85e in zend_signal_handler_defer (signo=3, siginfo=0x7ffc1f34ca70, context=0x7ffc1f34c940) at /home/mickael/php/src/php-7.0.2/Zend/zend_signal.c:89
#3  <signal handler called>
#4  0x00007f282b6afdf0 in __accept_nocancel () from /usr/lib/libc.so.6
#5  0x00000000008cd24e in fcgi_accept_request (req=0x1fc2860) at /home/mickael/php/src/php-7.0.2/main/fastcgi.c:1396
#6  0x00000000008dc5ba in main (argc=4, argv=0x7ffc1f34d418) at /home/mickael/php/src/php-7.0.2/sapi/fpm/fpm/fpm_main.c:187
 [2016-01-08 19:42 UTC] mickael9 at gmail dot com 
I think the child is not properly handling the received SIGQUIT coming from the php-fpm master. Instead of stopping gracefully, it generates a coredump (almost as if the SIGQUIT was not properly assigned to the correct signal handler)
 [2016-01-08 23:57 UTC] mickael9 at gmail dot com 
I studied this more, I'm pretty sure this is what is happening :

1) php-fpm forks a child
2) fpm_signals_init_child() gets called which sets the correct handler for SIGQUIT
3) later, php_request_startup() gets called
4) php_request_startup() calls zend_signal_activate()
5) zend_signal_activate() resets all signal handlers, including SIGQUIT, overriding the correct ones.
6) when the master decides to terminate a child it sends SIGQUIT to the child which dumps core instead of gracefully exiting because the signal handler was overwritten
 [2016-01-25 01:46 UTC] jeff at keyte dot me 
So is this related to php-fpm or owncloud?  Just wondering where to direct my attention for a fix.

Thanks.
 [2016-01-25 01:52 UTC] mickael9 at gmail dot com 
It's a bug in php-fpm. I already proposed a fix (see attached pull request) : https://github.com/php/php-src/pull/1720
 [2016-03-04 13:10 UTC] maarten@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: maarten
 [2016-03-04 13:10 UTC] maarten@php.net 
Thank you for your bug report. This issue has already been fixed
in the latest released version of PHP, which you can download at 
http://www.php.net/downloads.php

Mentioned as fixed in 7.0.4 :)
http://php.net/ChangeLog-7.php#7.0.4
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Nov 23 15:01:29 2024 UTC