Edit report at https://bugs.php.net/bug.php?id=77289&edit=1
ID: 77289
Comment by: lauri dot kentta at gmail dot com
Reported by: bugs dot php dot net at mundpropaganda dot net
Summary: php-fpm workers are segfaulting intermittently
Status: Open
Type: Bug
Package: opcache
Operating System: Linux 4.14.82
PHP Version: 7.3.0
Block user comment: N
Private report: N
New Comment:
Sometimes php-fpm child segfaults in zend_mm_alloc_small or calls exit(1) in zend_mm_panic.
I've managed to cut it down to this weird test case:
<?php
// Run with FastCGI 100 times in a row. Look at php-fpm log.
$pdo = new PDO("mysql:host=localhost", "root", "", array(
PDO::ATTR_PERSISTENT => true,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
));
$pdo->exec("DROP DATABASE IF EXISTS tmp_database");
$pdo->exec("CREATE DATABASE tmp_database");
$pdo->exec("DROP TABLE IF EXISTS tmp_database.tmp_table");
$pdo->exec("CREATE TEMPORARY TABLE tmp_database.tmp_table (x INT)");
$pdo->exec("UPDATE tmp_database.tmp_table SET x = x");
?>
This triggers the bug in around 10 % of runs. Note that this is visible only in the php-fpm console
("child ... exited with code 1"), not in the script itself.
Disabling opcache makes the bug actually easier to reproduce.
In 7.3.0 the bug was also triggered by a slightly more complex test case containing autoload and
eval (and MySQL UPDATE), and in that case, string lengths (like the length of the autoloaded class
name) affected whether the bug was triggered or not. Also, my test case had originally a few hundred
lines (real-life code with real-life input), and even changing some unused code or changing the
length of some unused string literals (especially around 16 chars) would change the frequency of the
bug, sometimes even make it disappear. That's why I'm tempted to blame either strings or
memory management in general.
However, I couldn't reproduce this at all without MySQL, so it could still be a MySQL-related
bug. I even bisected this to commit 4d5330fb, but reverting it didn't fix the problem.
Previous Comments:
------------------------------------------------------------------------
[2019-01-02 11:27:36] nikic@php.net
Assuming this only happens with opcache (based on the package), the first two things to try would
be:
* Set opcache.optimization_level=0 and see if this resolves the issue.
* Set opcache.protect_memory=1 and see if you get reproducible segfaults. A backtrace from one of
those should pinpoint the location.
I'd also recommend testing with a current snapshot of PHP 7.3, as a number of opcache-related
bugs have already been fixed, but not released yet.
------------------------------------------------------------------------
[2018-12-27 09:43:10] lauri dot kentta at gmail dot com
I get these crashes with my custom site. It's not related to some specific path or time.
Sometimes it's 1.8 seconds from start, sometimes 6 hours, after 1500 requests on average. I
can't yet reproduce it reliably.
I suspect that something bad is happening with strings or memory allocation.
A bit before the crash, I often see âchild [PID] exited with code 1â. And sometimes,
instead of a crash, my site starts producing other fatal errors with clearly corrupted code.
âCall to undefined method ClassA::ClassB::ConstInClassB()â where actually ClassA::foo() is
called, or an SQL error of a missing table dbname.FOO, where FOO occurs in many other contexts but
certainly not in static::$db_table.
Could some PHP core developer guess how this kind of corruption could happen? Maybe reviewing
related changes between 7.2.13 and 7.3.0 could then be useful. (What is the best git command for
that, considering the way PHP branches are forked?)
------------------------------------------------------------------------
[2018-12-18 15:43:41] bugs dot php dot net at mundpropaganda dot net
Related To: Bug #77312
------------------------------------------------------------------------
[2018-12-12 16:10:27] bugs dot php dot net at mundpropaganda dot net
Description:
------------
Hey there,
after upgrading from PHP 7.2.13 to to 7.3.0 I noticed php-fpm workers frequently crashing while
serving WordPress. Downgrading back to 7.2.13 fixed all issues.
The crashes seem to happen after I empty the cache of the wp-supercache plugin and access a
previously uncached page of the website, although they are rather intermittent; sometimes occurring
immediately, sometimes I have to click around a bit for it to trigger and other times it works just
fine.
I was able to dump the core of a worker process when it happened:
Core was generated by php-fpm: pool amm-php73.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 zend_mm_alloc_small (bin_num=4, size=40, heap=0x7f9fea600040)
at /home/krist/tmp/php-7.3.0/Zend/zend_alloc.c:1287
#1 zend_mm_alloc_heap (size=40, heap=0x7f9fea600040)
at /home/krist/tmp/php-7.3.0/Zend/zend_alloc.c:1358
#2 _emalloc (size=size@entry=40) at /home/krist/tmp/php-7.3.0/Zend/zend_alloc.c:2498
#3 0x000055e2dc8d84aa in zend_string_alloc (persistent=0, len=8)
at /home/krist/tmp/php-7.3.0/Zend/zend_string.h:155
#4 zend_string_init (persistent=0, len=8, str=<optimized out>)
at /home/krist/tmp/php-7.3.0/Zend/zend_string.h:155
#5 lex_scan (zendlval=zendlval@entry=0x7ffcbae3dbc0, elem=0x7ffcbae3dc48)
at Zend/zend_language_scanner.l:2760
#6 0x000055e2dc8ebe4a in zendlex (elem=elem@entry=0x7ffcbae3dc48)
at /home/krist/tmp/php-7.3.0/Zend/zend_compile.c:1693
#7 0x000055e2dc8d172e in zendparse () at /home/krist/tmp/php-7.3.0/Zend/zend_language_parser.c:4211
#8 0x000055e2dc8d3c2a in zend_compile (type=type@entry=2) at Zend/zend_language_scanner.l:586
#9 0x000055e2dc8d540a in compile_file (file_handle=0x7ffcbae3ebc0, type=2)
at Zend/zend_language_scanner.l:636
#10 0x000055e2dc7ada72 in phar_compile_file (file_handle=0x7ffcbae3ebc0, type=2)
at /home/krist/tmp/php-7.3.0/ext/phar/phar.c:3344
#11 0x00007f9fea8a106c in opcache_compile_file (file_handle=0x7ffcbae3ebc0, type=2,
op_array_p=0x7ffcbae3eaa8, key=<optimized out>)
at /home/krist/tmp/php-7.3.0/ext/opcache/ZendAccelerator.c:1750
#12 0x00007f9fea8a332f in persistent_compile_file (type=2, file_handle=0x7ffcbae3ebc0)
at /home/krist/tmp/php-7.3.0/ext/opcache/ZendAccelerator.c:2095
#13 persistent_compile_file (file_handle=0x7ffcbae3ebc0, type=2)
at /home/krist/tmp/php-7.3.0/ext/opcache/ZendAccelerator.c:1889
#14 0x000055e2dc8d54b2 in compile_filename (type=type@entry=2,
filename=filename@entry=0x7f9fea61da40)
at Zend/zend_language_scanner.l:661
#15 0x000055e2dc94dc65 in zend_include_or_eval (inc_filename=inc_filename@entry=0x7f9fea61da40,
type=2) at /home/krist/tmp/php-7.3.0/Zend/zend_execute.c:3182
#16 0x000055e2dc983d10 in ZEND_INCLUDE_OR_EVAL_SPEC_TMPVAR_HANDLER ()
at /home/krist/tmp/php-7.3.0/Zend/zend_vm_execute.h:12697
#17 0x000055e2dc989f0f in execute_ex (ex=0x861e00)
at /home/krist/tmp/php-7.3.0/Zend/zend_vm_execute.h:56832
#18 0x000055e2dc990702 in zend_execute (op_array=op_array@entry=0x7f9fe339f958, return_value=0x0,
return_value@entry=0x7f9fea61d9a0) at /home/krist/tmp/php-7.3.0/Zend/zend_vm_execute.h:60834
#19 0x000055e2dc90ad83 in zend_execute_scripts (type=type@entry=8, retval=0x7f9fea61d9a0,
retval@entry=0x0, file_count=file_count@entry=3) at /home/krist/tmp/php-7.3.0/Zend/zend.c:1568
#20 0x000055e2dc8ac228 in php_execute_script (primary_file=<optimized out>)
at /home/krist/tmp/php-7.3.0/main/main.c:2630
#21 0x000055e2dc69f290 in main (argc=<optimized out>, argv=<optimized out>)
at /home/krist/tmp/php-7.3.0/sapi/fpm/fpm/fpm_main.c:1950
Let me know if there's anything I might do or provide to help tracing this bug.
â Christian
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=77289&edit=1