View Issue Details

IDProjectCategoryView StatusLast Update
0001460XdebugUncategorizedpublic2017-10-17 12:03
Reporterrinu Assigned Toderick  
Status resolvedResolutionno change required 
OSUbuntuOS Version16.04 
Summary0001460: ext/opcache/Optimizer/dce.c:584: dce_live_ranges: Assertion `op_array->opcodes[def].result_type & ((1<<1)|(1<<2))' failed.
DescriptionXdebug (master branch) compiles and installs ok with PHP 7.2 but running any non-trivial code under FPM will result in this error, making PHP unusable.
TagsNo tags attached.
Operating System
PHP Version7.2-dev



2017-08-08 11:40

administrator   ~0004390

I'm going to need a back trace, and the smallest bit of code you can produce that triggers this (on the CLI) please.

Information on how to make a backtrace is at

Please run "export USE_ZEND_ALLOC=0" on the shell first, before "php script-that-crashes.php".


2017-08-08 12:46

reporter   ~0004391

Cannot reproduce in CLI mode, only FPM.
When I try starting FPM manually, I get this:
ext/opcache/ZendAccelerator.c:634: accel_replace_string_by_process_permanent: Assertion `0' failed.

The "Generic way to get a core on Linux" has never worked for me. No idea why. So starting FPM manually with gdb was my only chance for backtrace.

When FPM runs as a service, this code will reproduce the original crash:
class test {
    protected $type;
    protected static $instances = [];

    public function __construct($type) {
        $this->type = $type;

    public static function getInstance($type) {
        self::$instances[$type] = new self($type);
        return self::$instances[$type];


2017-08-08 12:52

administrator   ~0004392

Getting a back trace can indeed be fiddly - as you say you have one, did you forget to attach it to the report?


2017-08-08 13:06

reporter   ~0004393

I didn't get a bt for this crash but I reported a php bug for the next issue I found here:

How am I going to get a bt for this issue? I ran FPM with gdb and only got the bt for the other issue, not this one.


2017-09-22 08:41

reporter   ~0004422

I finally got a core dump file. I hope I made the back trace correctly and this issue can be resolved.
This is using PHP 7.2 RC2 and xdebug master branch.

(gdb) bt
#0 0x00007ffff4cc5428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4cc702a in __GI_abort () at abort.c:89
0000002 0x00007ffff4cbdbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7fffecc9f378 "op_array->opcodes[def].result_type & ((1<<1)|(1<<2))",
    file=file@entry=0x7fffecc9f2d0 "/php-src/ext/opcache/Optimizer/dce.c", line=line@entry=584, function=function@entry=0x7fffecc9f460 <__PRETTY_FUNCTION__.10820> "dce_live_ranges") at assert.c:92
0000003 0x00007ffff4cbdc82 in __GI___assert_fail (assertion=0x7fffecc9f378 "op_array->opcodes[def].result_type & ((1<<1)|(1<<2))", file=0x7fffecc9f2d0 "/php-src/ext/opcache/Optimizer/dce.c", line=584,
    function=0x7fffecc9f460 <__PRETTY_FUNCTION__.10820> "dce_live_ranges") at assert.c:101
0000004 0x00007fffecc878de in dce_live_ranges (ctx=0x7fffffffb430, op_array=0x7fffed411038, ssa=0x7fffed5086e8) at /php-src/ext/opcache/Optimizer/dce.c:584
0000005 0x00007fffecc88085 in dce_optimize_op_array (op_array=0x7fffed411038, ssa=0x7fffed5086e8, reorder_dtor_effects=0 '\000') at /php-src/ext/opcache/Optimizer/dce.c:686
0000006 0x00007fffecc4fcbe in zend_dfa_optimize_op_array (op_array=0x7fffed411038, ctx=0x7fffffffb710, ssa=0x7fffed5086e8, call_map=0x7fffed50c4e0) at /php-src/ext/opcache/Optimizer/dfa_pass.c:570
0000007 0x00007fffecc31794 in zend_optimize_script (script=0x7fffed495000, optimization_level=2147467263, debug_level=0) at /php-src/ext/opcache/Optimizer/zend_optimizer.c:1262
0000008 0x00007fffecc0ca08 in cache_script_in_shared_memory (new_persistent_script=0x7fffed495000, key=0x7fffed489498 "/var/www/app.php", key_length=28, from_shared_memory=0x7fffffffb7c0)
    at /php-src/ext/opcache/ZendAccelerator.c:1321
0000009 0x00007fffecc0e69b in persistent_compile_file (file_handle=0x7fffffffb930, type=8) at /php-src/ext/opcache/ZendAccelerator.c:1922
0000010 0x00007fffec9bb334 in xdebug_compile_file (file_handle=0x7fffffffb930, type=8) at /home/rauno/xdebug/xdebug.c:1960
0000011 0x0000000000baadb0 in zend_include_or_eval (inc_filename=0x7fffdd0781c0, type=16) at /php-src/Zend/zend_execute.c:2802
0000012 0x0000000000bb3019 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER () at /php-src/Zend/zend_vm_execute.h:3440
0000013 0x0000000000baf7e3 in ZEND_USER_OPCODE_SPEC_HANDLER () at /php-src/Zend/zend_vm_execute.h:1832
0000014 0x0000000000c327f6 in execute_ex (ex=0x7fffed41f030) at /php-src/Zend/zend_vm_execute.h:59815
0000015 0x00007fffec9bab2b in xdebug_execute_ex (execute_data=0x7fffed41f030) at /home/rauno/xdebug/xdebug.c:1801
0000016 0x0000000000c37a6d in zend_execute (op_array=0x7fffed465300, return_value=0x0) at /php-src/Zend/zend_vm_execute.h:63763
0000017 0x0000000000b47cb3 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /php-src/Zend/zend.c:1494
0000018 0x0000000000aac10c in php_execute_script (primary_file=0x7fffffffe060) at /php-src/main/main.c:2565
0000019 0x0000000000c4aa9a in main (argc=1, argv=0x7fffffffe4f8) at /php-src/sapi/fpm/fpm/fpm_main.c:1966


2017-10-15 14:07

administrator   ~0004440

Currently, I am getting errors without Xdebug enabled and just running "php run-tests.php". I'll keep monitoring this, but I don't think it's an xdebug issue.


2017-10-16 17:22

reporter   ~0004441

Well, my script does not crash when I disable xdebug and will always crash with xdebug enabled. Can't see how this is not an xdebug issue.

The other PHP bug mentioned in this issue got resolved. This issue remains, just tried again with 7.2.0RC4 and the latest xdebug master.


2017-10-17 12:03

administrator   ~0004442

The problem was indeed not in Xdebug, but with just PHP. You should be able to simulate it by passing the -e option on the PHP CLI. This adds extra opcodes in the op arrays for Xdebug (and other tools) to use. Xdebug forces this option to always be on.

In any case, it just got fixed in PHP itself, so I'm closing this issue:

Issue History

Date Modified Username Field Change
2017-08-08 11:36 rinu New Issue
2017-08-08 11:40 derick Note Added: 0004390
2017-08-08 11:40 derick Assigned To => derick
2017-08-08 11:40 derick Status new => feedback
2017-08-08 12:46 rinu Note Added: 0004391
2017-08-08 12:46 rinu Status feedback => assigned
2017-08-08 12:52 derick Note Added: 0004392
2017-08-08 13:06 rinu Note Added: 0004393
2017-09-22 08:41 rinu Note Added: 0004422
2017-10-15 14:07 derick Note Added: 0004440
2017-10-16 17:22 rinu Note Added: 0004441
2017-10-17 12:03 derick Note Added: 0004442
2017-10-17 12:03 derick Status assigned => resolved
2017-10-17 12:03 derick Resolution open => no change required
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized