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.

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.

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.

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

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)

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

So is this related to php-fpm or owncloud?  Just wondering where to direct my attention for a fix.

Thanks.

It's a bug in php-fpm. I already proposed a fix (see attached pull request) : https://github.com/php/php-src/pull/1720

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