Hi,

I"m going to need a (short) script to reproduce this. Please note, that 2.7.0-beta1 is still a pre-release version, and that there are still issues with it. A short script to reproduce this will expedite fixes.

cheers,
Derick

Ok, I've got one. It only crashes in the FPM SAPI in my testing and not CLI.

PHP:
<?php
class Foo
{
public function __destruct() { $this->shutdown(); }
public function shutdown($how=STREAM_SHUT_RDWR) { }
}

function get_it()
{
return false;

}

$x = new Foo();
$x->shutdown();
echo json_encode(['x'=>get_it()]);

GDB (BT):
#0 i_free_compiled_variables (execute_data=0x2aaaad420080) at /build/php7.3-7.3.0~rc3/Zend/zend_execute.c:2351
#1 zend_leave_helper_SPEC (execute_data=0x2aaaad420080) at /build/php7.3-7.3.0~rc3/Zend/zend_vm_execute.h:589
0000002 0x0000555555802170 in execute_ex (ex=<optimized out>) at /build/php7.3-7.3.0~rc3/Zend/zend_vm_execute.h:55287
0000003 0x00002aaaad89a7bc in xdebug_execute_ex (execute_data=0x2aaaad420080)
at /build/xdebug-2.7.0~beta1+2.6.1+2.5.5/build-7.3/xdebug.c:1868
0000004 0x0000555555851299 in ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (execute_data=0x2aaaad420030)
at /build/php7.3-7.3.0~rc3/Zend/zend_vm_execute.h:961
0000005 0x0000555555802170 in execute_ex (ex=<optimized out>) at /build/php7.3-7.3.0~rc3/Zend/zend_vm_execute.h:55287
0000006 0x00002aaaad89a7bc in xdebug_execute_ex (execute_data=0x2aaaad420030)
at /build/xdebug-2.7.0~beta1+2.6.1+2.5.5/build-7.3/xdebug.c:1868
0000007 0x00005555557b71ba in zend_call_function (fci=fci@entry=0x7fffffffe560, fci_cache=<optimized out>, fci_cache@entry=0x7fffffffe540)
at /build/php7.3-7.3.0~rc3/Zend/zend_execute_API.c:756
0000008 0x00005555557f49ef in zend_objects_destroy_object (object=0x2aaaad470a78) at /build/php7.3-7.3.0~rc3/Zend/zend_objects.c:158
0000009 0x00005555557f9cbc in zend_objects_store_del (object=0x2aaaad470a78) at /build/php7.3-7.3.0~rc3/Zend/zend_objects_API.c:170
0000010 0x00005555557d5c45 in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=7, ht=<optimized out>)
at /build/php7.3-7.3.0~rc3/Zend/zend_hash.c:1181
0000011 _zend_hash_del_el (p=0x2aaaad4662e0, idx=7, ht=0x555555bb23b0) at /build/php7.3-7.3.0~rc3/Zend/zend_hash.c:1204
0000012 zend_hash_reverse_apply (ht=ht@entry=0x555555bb23b0, apply_func=apply_func@entry=0x5555557b5a20 <zval_call_destructor>)
at /build/php7.3-7.3.0~rc3/Zend/zend_hash.c:1775
0000013 0x00005555557b5e55 in shutdown_destructors () at /build/php7.3-7.3.0~rc3/Zend/zend_execute_API.c:240
0000014 0x00005555557c5267 in zend_call_destructors () at /build/php7.3-7.3.0~rc3/Zend/zend.c:1089
0000015 0x000055555576322d in php_request_shutdown (dummy=dummy@entry=0x0) at /build/php7.3-7.3.0~rc3/main/main.c:1873
0000016 0x000055555562578b in main (argc=<optimized out>, argv=<optimized out>) at /build/php7.3-7.3.0~rc3/sapi/fpm/fpm/fpm_main.c:1975

GDB PHP:
[0x2aaaad420080] Foo->shutdown() /<redacted>/crash.php:5
[0x2aaaad420030] Foo->__destruct() /<redacted>/crash.php:4
[0x7fffffffe4a0] ???

NOTES:

• Changing $how=STREAM_SHUT_RDWR to $how=1 fixes the issue.
• Removing the call to get_it() and just using 'false' fixes the issue.

FWIW, this issue is only reproducible with Opcache loaded.

@morozov Aha! That explains why I couldn't reproduce it in the CLI!

Now I can:

% gdb --ex=r --args php7.3 -dzend_extension=xdebug.so -dopcache.enable_cli=On crash.php

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/php7.3...Reading symbols from /usr/lib/debug/.build-id/a4/0643386852dbb9b42577955d32bf91ff2f77ce.debug...done.
done.
Starting program: /usr/bin/php7.3 -dzend_extension=xdebug.so -dopcache.enable_cli=On crash.php
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaacb000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
{"x":false}
Program received signal SIGSEGV, Segmentation fault.
i_free_compiled_variables (execute_data=0x2aaaad21e080) at /build/php7.3-7.3.0~rc4/Zend/zend_execute.c:2351
2351 /build/php7.3-7.3.0~rc4/Zend/zend_execute.c: No such file or directory.

I can reproduce this:

valgrind php -n -dzend_extension=xdebug.so -dzend_extension=opcache.so -dopcache.enable_cli=1 1583.php

Shows:

==23877== Memcheck, a memory error detector

==23877== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.

==23877== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info

==23877== Command: php -n -dzend_extension=xdebug.so -dzend_extension=opcache.so -dopcache.enable_cli=1 1583.php

==23877==

==23877== Conditional jump or move depends on uninitialised value(s)

==23877==    at 0x9FEACD: ZEND_RECV_INIT_SPEC_CONST_HANDLER (zend_vm_execute.h:2229)

==23877==    by 0x9FDA67: ZEND_USER_OPCODE_SPEC_HANDLER (zend_vm_execute.h:1829)

==23877==    by 0xA62805: execute_ex (zend_vm_execute.h:55510)

==23877==    by 0x86C15CA: xdebug_execute_ex (xdebug.c:1868)

==23877==    by 0x9FB101: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:961)

==23877==    by 0x9FDA67: ZEND_USER_OPCODE_SPEC_HANDLER (zend_vm_execute.h:1829)

==23877==    by 0xA62805: execute_ex (zend_vm_execute.h:55510)

==23877==    by 0x86C15CA: xdebug_execute_ex (xdebug.c:1868)

==23877==    by 0xA67D16: zend_execute (zend_vm_execute.h:60834)

==23877==    by 0x997069: zend_execute_scripts (zend.c:1568)

==23877==    by 0x906D4D: php_execute_script (main.c:2630)

==23877==    by 0xA6A79E: do_cli (php_cli.c:997)

==23877==

{"x":false}==23877== Invalid read of size 4

==23877==    at 0x9EF704: zend_gc_delref (zend_types.h:996)

==23877==    by 0x9F728B: i_free_compiled_variables (zend_execute.c:2351)

==23877==    by 0x9FA1A0: zend_leave_helper_SPEC (zend_vm_execute.h:589)

==23877==    by 0x9FFF2D: ZEND_RETURN_SPEC_CONST_HANDLER (zend_vm_execute.h:2758)

==23877==    by 0x9FDA67: ZEND_USER_OPCODE_SPEC_HANDLER (zend_vm_execute.h:1829)

==23877==    by 0xA62805: execute_ex (zend_vm_execute.h:55510)

==23877==    by 0x86C15CA: xdebug_execute_ex (xdebug.c:1868)

==23877==    by 0x9FB101: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:961)

==23877==    by 0x9FDA67: ZEND_USER_OPCODE_SPEC_HANDLER (zend_vm_execute.h:1829)

==23877==    by 0xA62805: execute_ex (zend_vm_execute.h:55510)

==23877==    by 0x86C15CA: xdebug_execute_ex (xdebug.c:1868)

==23877==    by 0x98017C: zend_call_function (zend_execute_API.c:756)

==23877==  Address 0x800000000000002 is not stack'd, malloc'd or (recently) free'd

==23877==

==23877==

==23877== Process terminating with default action of signal 11 (SIGSEGV)

==23877==  General Protection Fault

==23877==    at 0x9EF704: zend_gc_delref (zend_types.h:996)

==23877==    by 0x9F728B: i_free_compiled_variables (zend_execute.c:2351)

==23877==    by 0x9FA1A0: zend_leave_helper_SPEC (zend_vm_execute.h:589)

==23877==    by 0x9FFF2D: ZEND_RETURN_SPEC_CONST_HANDLER (zend_vm_execute.h:2758)

==23877==    by 0x9FDA67: ZEND_USER_OPCODE_SPEC_HANDLER (zend_vm_execute.h:1829)

==23877==    by 0xA62805: execute_ex (zend_vm_execute.h:55510)

==23877==    by 0x86C15CA: xdebug_execute_ex (xdebug.c:1868)

==23877==    by 0x9FB101: ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER (zend_vm_execute.h:961)

==23877==    by 0x9FDA67: ZEND_USER_OPCODE_SPEC_HANDLER (zend_vm_execute.h:1829)

==23877==    by 0xA62805: execute_ex (zend_vm_execute.h:55510)

==23877==    by 0x86C15CA: xdebug_execute_ex (xdebug.c:1868)

==23877==    by 0x98017C: zend_call_function (zend_execute_API.c:756)

==23877==

==23877== HEAP SUMMARY:

==23877==     in use at exit: 2,879,895 bytes in 24,279 blocks

==23877==   total heap usage: 26,787 allocs, 2,508 frees, 3,875,685 bytes allocated

The first error is the same one as in 0001592, so these issues could as well be related.

Full backtrace on PHP 7.3.0 with OpCache optimizer bug (PHP#77275) fixed:

#0 i_free_compiled_variables (execute_data=<optimized out>) at ./Zend/zend_execute.c:2351
r = 0x800000000000002
cv = 0x7ffff481e0d0
count = 1
cv = <optimized out>
count = <optimized out>
r = <optimized out>
#1 zend_leave_helper_SPEC () at ./Zend/zend_vm_execute.h:589
old_execute_data = <optimized out>
call_info = 2
0000002 0x000055555587aaf7 in execute_ex (ex=0x800000000000002) at ./Zend/zend_vm_execute.h:55510
orig_opline = 0x7ffff480e7d8
orig_execute_data = <optimized out>
0000003 0x00007ffff4acff03 in xdebug_execute_ex (execute_data=0x7ffff481e080) at ./build-7.3/xdebug.c:1868
op_array = 0x7fffec6bebb0
edata = <optimized out>
fse = 0x555555b7bbd0
xfse = <optimized out>
do_return = 0
function_nr = 6
le = <optimized out>
code_coverage_func_info = {class = 0x0, function = 0x555555a9ec80 "p\273\267UUU", type = 2, internal = 0}
code_coverage_function_name = 0x0
code_coverage_file_name = 0x7ffff481e080 "\260\353k\354\377\177"
code_coverage_init = 0
0000004 0x0000555555651ea3 in ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER () at ./Zend/zend_vm_execute.h:961
call = 0x7ffff481e080
fbc = 0x7ffff480e7d8
object = <optimized out>
ret = 0x0
retval = <optimized out>
retval = <optimized out>
0000005 0x000055555587aaf7 in execute_ex (ex=0x800000000000002) at ./Zend/zend_vm_execute.h:55510
orig_opline = 0x7ffff480e700
orig_execute_data = <optimized out>
0000006 0x00007ffff4acff03 in xdebug_execute_ex (execute_data=0x7ffff481e030) at ./build-7.3/xdebug.c:1868
op_array = 0x7fffec6bea90
edata = <optimized out>
fse = 0x555555a9ec80
xfse = <optimized out>
do_return = 0
function_nr = 5
le = <optimized out>
code_coverage_func_info = {class = 0x5555559f9940 <executor_globals> "", function = 0x7ffff480e540 "\002", type = -192815056, internal = 32767}
code_coverage_function_name = 0x0
code_coverage_file_name = 0x7ffff481e030 "\220\352k\354\377\177"
code_coverage_init = 0
0000007 0x00005555557ec68e in zend_call_function (fci=fci@entry=0x7fffffffc8b0, fci_cache=<optimized out>, fci_cache@entry=0x7fffffffc890)
at ./Zend/zend_execute_API.c:756
call_via_handler = 0
current_opline_before_exception = 0x0
i = <optimized out>
call = 0x7ffff481e030
dummy_execute_data = {opline = 0x0, call = 0x0, return_value = 0x0, func = 0x0, This = {value = {lval = 0, dval = 0, counted = 0x0, str = 0x0,
arr = 0x0, obj = 0x0, res = 0x0, ref = 0x0, ast = 0x0, zv = 0x0, ptr = 0x0, ce = 0x0, func = 0x0, ww = {w1 = 0, w2 = 0}}, u1 = {v = {
type = 0 '\000', type_flags = 0 '\000', u = {call_info = 0, extra = 0}}, type_info = 0}, u2 = {next = 0, cache_slot = 0, opline_num = 0,
lineno = 0, num_args = 0, fe_pos = 0, fe_iter_idx = 0, access_flags = 0, property_guard = 0, constant_flags = 0, extra = 0}},
prev_execute_data = 0x0, symbol_table = 0x0, run_time_cache = 0x0}
fci_cache_local = {function_handler = 0x7fffffffc830, calling_scope = 0x555555898f8d, called_scope = 0x0, object = 0x555555a9c280}
func = 0x7ffff480e700
0000008 0x000055555582a05d in zend_objects_destroy_object (object=0x7ffff4866618) at ./Zend/zend_objects.c:158
old_exception = 0x0
ret = {value = {lval = 0, dval = 0, counted = 0x0, str = 0x0, arr = 0x0, obj = 0x0, res = 0x0, ref = 0x0, ast = 0x0, zv = 0x0, ptr = 0x0, ce = 0x0,
func = 0x0, ww = {w1 = 0, w2 = 0}}, u1 = {v = {type = 0 '\000', type_flags = 0 '\000', u = {call_info = 0, extra = 0}}, type_info = 0}, u2 = {
next = 21845, cache_slot = 21845, opline_num = 21845, lineno = 21845, num_args = 21845, fe_pos = 21845, fe_iter_idx = 21845, access_flags = 21845,
property_guard = 21845, constant_flags = 21845, extra = 21845}}
orig_fake_scope = 0x0
fci = {size = 56, function_name = {value = {lval = 0, dval = 0, counted = 0x0, str = 0x0, arr = 0x0, obj = 0x0, res = 0x0, ref = 0x0, ast = 0x0,
zv = 0x0, ptr = 0x0, ce = 0x0, func = 0x0, ww = {w1 = 0, w2 = 0}}, u1 = {v = {type = 0 '\000', type_flags = 0 '\000', u = {call_info = 0,
extra = 0}}, type_info = 0}, u2 = {next = 0, cache_slot = 0, opline_num = 0, lineno = 0, num_args = 0, fe_pos = 0, fe_iter_idx = 0,
access_flags = 0, property_guard = 0, constant_flags = 0, extra = 0}}, retval = 0x7fffffffc880, params = 0x0, object = 0x7ffff4866618,
no_separation = 1 '\001', param_count = 0}
fcic = {function_handler = 0x7ffff480e700, calling_scope = 0x55555582a590 <zend_objects_clone_obj>, called_scope = 0x7ffff480e540,
object = 0x7ffff4866618}
destructor = 0x7ffff480e700
0000009 0x000055555582f02f in zend_objects_store_del (object=0x7ffff4866618) at ./Zend/zend_objects_API.c:170
No locals.
0000010 0x000055555580aa40 in _zend_hash_del_el_ex (prev=<optimized out>, p=<optimized out>, idx=9, ht=<optimized out>) at ./Zend/zend_hash.c:1181
tmp = {value = {lval = 140737295836696, dval = 6.9533462961507788e-310, counted = 0x7ffff4866618, str = 0x7ffff4866618, arr = 0x7ffff4866618,
obj = 0x7ffff4866618, res = 0x7ffff4866618, ref = 0x7ffff4866618, ast = 0x7ffff4866618, zv = 0x7ffff4866618, ptr = 0x7ffff4866618,
ce = 0x7ffff4866618, func = 0x7ffff4866618, ww = {w1 = 4102448664, w2 = 32767}}, u1 = {v = {type = 8 '\b', type_flags = 1 '\001', u = {
call_info = 0, extra = 0}}, type_info = 264}, u2 = {next = 0, cache_slot = 0, opline_num = 0, lineno = 0, num_args = 0, fe_pos = 0,
fe_iter_idx = 0, access_flags = 0, property_guard = 0, constant_flags = 0, extra = 0}}
0000011 _zend_hash_del_el (p=0x7ffff4861320, idx=9, ht=0x5555559f9a70 <executor_globals+304>) at ./Zend/zend_hash.c:1204
prev = <optimized out>
prev = <optimized out>
nIndex = <optimized out>
i = <optimized out>
0000012 zend_hash_reverse_apply (ht=ht@entry=0x5555559f9a70 <executor_globals+304>, apply_func=apply_func@entry=0x5555557eae60 <zval_call_destructor>)
at ./Zend/zend_hash.c:1775
idx = <optimized out>
p = 0x7ffff4861320
result = <optimized out>
0000013 0x00005555557eb2a5 in shutdown_destructors () at ./Zend/zend_execute_API.c:240
symbols = <optimized out>
orig_bailout = 0x7fffffffcae0
bailout = {{jmpbuf = {93824997103936, 768434357834357521, 93824995976456, 93824995976496, 1, 93824997197024, 6917337964184607505,
768434625227135761}, mask_was_saved = 0, saved_mask = {val = {140737488343800, 140737488343712, 0, 140737488341664, 93824995635903, 0, 0,
0, 0, 0, 11, 0, 0, 0, 0, 0}}}}
0000014 0x00005555557fa225 in zend_call_destructors () at ./Zend/zend.c:1089
orig_bailout = 0x7fffffffcce0
bailout = {{jmpbuf = {93824997103936, 768434357834357521, 93824995976456, 93824995976496, 1, 93824997197024, 6917337964218161937,
768434633232620305}, mask_was_saved = 0, saved_mask = {val = {93824997757696, 0, 0, 0, 4194213060263121664, 0, 93824997483600,
93824997102232, 0, 93824995976496, 1, 93824997197024, 93824994960221, 93824997102232, 93824997101920, 93824995976456}}}}
0000015 0x000055555579a175 in php_request_shutdown (dummy=<optimized out>) at ./main/main.c:1873
orig_bailout = <optimized out>
bailout = {{jmpbuf = {93824997103936, 768434357834357521, 93824995976456, 93824995976496, 1, 93824997197024, 6917337964253813521,
768434615912373009}, mask_was_saved = 0, saved_mask = {val = {93824997122072, 31, 80, 18446744073709550456, 0, 112, 206158430248,
140737488344080, 140737488343888, 140737488344096, 140737488343904, 111, 160, 18446744073709550456, 2, 214748364808}}}}
report_memleaks = 1 '\001'
0000016 0x00005555558829ca in do_cli (argc=3, argv=0x555555a10470) at ./sapi/cli/php_cli.c:1164
c = <optimized out>
file_handle = {handle = {fd = -192425968, fp = 0x7ffff487d010, stream = {handle = 0x7ffff487d010, isatty = 0, mmap = {len = 250, pos = 0,
map = 0x7ffff4a02000, buf = 0x7ffff4a02000 <error: Cannot access memory at address 0x7ffff4a02000>, old_handle = 0x555555a2cfa0,
old_closer = 0x555555815170 <zend_stream_stdio_closer>}, reader = 0x5555558151a0 <zend_stream_stdio_reader>,
fsizer = 0x555555815280 <zend_stream_stdio_fsizer>, closer = 0x555555815100 <zend_stream_mmap_closer>}},
filename = 0x555555a104e0 "/tmp/crash.php", opened_path = 0x0, type = ZEND_HANDLE_MAPPED, free_filename = 0 '\000'}
behavior = <optimized out>
reflection_what = <optimized out>
request_started = 1
exit_status = 0
php_optarg = 0x555555a104c2 "opcache.enable_cli=On"
php_optind = 3
exec_direct = <optimized out>
exec_run = <optimized out>
exec_begin = <optimized out>
exec_end = <optimized out>
arg_free = <optimized out>
arg_excp = <optimized out>
script_file = <optimized out>
translated_path = 0x555555b7cbf0 "/tmp/crash.php"
lineno = 1
param_error = <optimized out>
hide_argv = <optimized out>
0000017 0x000055555566184f in main (argc=3, argv=0x555555a10470) at ./sapi/cli/php_cli.c:1389
orig_bailout = 0x0
bailout = {{jmpbuf = {93824997197664, 6917337965266213649, 22, 0, 93824995979524, 0, 6917337965222697745, 768434422431357713},
mask_was_saved = 0, saved_mask = {val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4194213060263121664, 93824997195384, 140737336741983, 0, 0, 0}}}}
c = <optimized out>
exit_status = 0
module_started = 1
sapi_started = 1
php_optarg = 0x555555a104c2 "opcache.enable_cli=On"
php_optind = 2
use_extended_info = 0
ini_path_override = 0x0
ini_entries = 0x555555a10760 "html_errors=0\nregister_argc_argv=1\nimplicit_flush=1\noutput_buffering=0\nmax_execution_time=0\nmax_input_time=-1\nopcache.enable_cli=On\n"
ini_entries_len = 22
ini_ignore = 0
sapi_module = <optimized out>

As I work around I have found disabling certain optimizations in opcache will avoid this bug.
setting this in php.ini will let me use xdebug fine.
opcache.optimization_level=0xFFFFFBFF

but setting it to:
opcache.optimization_level=0xFFFFFFFF
will cause this error.
I'm not sure which optimizations this bit corresponds to but hopefully it will help trace down the bug.

That 'B' would seem to align with this comment from php bug 77275:

We set in php.ini:
opcache.optimization_level=0x7FFFBBFF

The second 'B' represents the removal of 0x400, or ZEND_OPTIMIZER_PASS_11 (1<<10) / Merge equal constants /

Possibly related to (at a hunch/guess):

https://github.com/php/php-src/commit/1a63fa6ec9b0bacbb726e60c3c212e7d97b518c6

I can confirm this bug with the most recent Archlinux. Both using the CLI and the php-fpm the same effect as described above happens.

How can we help? What information is needed to track this down?

I'm still on my Christmas break so haven't had time to check this more in depth. It's quite possible that this is a bug in opcache as a related issue was fixed there too. I'll be back on the weekend to look at this again.

Right now, the workaround in (0004774) should work. (Turning off a specific opcache optimisation.)

I don't know if it is exactly the same issue, but I can reproduce something similar using the following script:

require_once(__DIR__ . '/../vendor/autoload.php');

class X {
    const DEFAULT_X = "xxx";

    public function __construct($x1, string $x2 = self::DEFAULT_X) {

    }
}

$x = new X([]);

Unfortunately my composer dependencies contain proprietary code, so I cannot post a self-contained test case. Commenting out the require_once makes the segfault disappear.

I'm running PHP 7.3.0 and Xdebug 2.7.0beta1 (both from deb.sury.org) on Debian Stretch, invoked using the CLI:

php -n -dzend_extension=xdebug.so -dzend_extension=opcache.so -dopcache.enable_cli=1 script.php

Variations tried:

• Without XDebug: no segfault occurs.
• Without Opcache: no segfault occurs.
• With the extra option -dopcache.optimization_level=0xFFFFFBFF: no segfault occurs
• Running the script using libapache2-mod-php7.3: results vary per invocation (probably related to different worker processes). Sometimes the script runs fine. Sometimes an error Uncaught TypeError: Argument 2 passed to X::__construct() must be of the type string, unknown given is shown. I've also seen this error with false instead of unknown.
• Without including the composer autoloader: no segfault occurs.

Running the script with valgrind ends with:

==222== Invalid read of size 8
==222==    at 0x39EDFD: zend_parse_arg_str_weak (in /usr/bin/php7.3)
==222==    by 0x3DFB5A: ??? (in /usr/bin/php7.3)
==222==    by 0x1EE967: ??? (in /usr/bin/php7.3)
==222==    by 0x4249EA: execute_ex (in /usr/bin/php7.3)
==222==    by 0xA2107A0: xdebug_execute_ex (xdebug.c:1868)
==222==    by 0x1EDE7A: ??? (in /usr/bin/php7.3)
==222==    by 0x4249EA: execute_ex (in /usr/bin/php7.3)
==222==    by 0xA2107A0: xdebug_execute_ex (xdebug.c:1868)
==222==    by 0x42CAA9: zend_execute (in /usr/bin/php7.3)
==222==    by 0x39DC82: zend_execute_scripts (in /usr/bin/php7.3)
==222==    by 0x33C727: php_execute_script (in /usr/bin/php7.3)
==222==    by 0x42EF2E: ??? (in /usr/bin/php7.3)
==222==  Address 0xe8 is not stack'd, malloc'd or (recently) free'd
==222==
==222==
==222== Process terminating with default action of signal 11 (SIGSEGV)
==222==  Access not within mapped region at address 0xE8
==222==    at 0x39EDFD: zend_parse_arg_str_weak (in /usr/bin/php7.3)
==222==    by 0x3DFB5A: ??? (in /usr/bin/php7.3)
==222==    by 0x1EE967: ??? (in /usr/bin/php7.3)
==222==    by 0x4249EA: execute_ex (in /usr/bin/php7.3)
==222==    by 0xA2107A0: xdebug_execute_ex (xdebug.c:1868)
==222==    by 0x1EDE7A: ??? (in /usr/bin/php7.3)
==222==    by 0x4249EA: execute_ex (in /usr/bin/php7.3)
==222==    by 0xA2107A0: xdebug_execute_ex (xdebug.c:1868)
==222==    by 0x42CAA9: zend_execute (in /usr/bin/php7.3)
==222==    by 0x39DC82: zend_execute_scripts (in /usr/bin/php7.3)
==222==    by 0x33C727: php_execute_script (in /usr/bin/php7.3)
==222==    by 0x42EF2E: ??? (in /usr/bin/php7.3)
==222==  If you believe this happened as a result of a stack
==222==  overflow in your program's main thread (unlikely but
==222==  possible), you can try to increase the size of the
==222==  main thread stack using the --main-stacksize= flag.
==222==  The main thread stack size used in this run was 8388608.

Hope this helps to narrow down the issue.

I dove a bit in the Arch build system and tried to recompile PHP (+ Co.) with debugging symbols and without optimization. Then I ran php-fpm through valgrind and triggered the problem. The results can be seen here: https://gist.github.com/christianlupus/b942a198960c2d9f276f42a5d6f5a6cf.

I hope this helps. If I can give more information or retry it with different configuration etc, please tell me.

With PHP 7.3.1 the workaround with "opcache.optimization_level=0x7FFFBBFF" is not working anymore. Unsure if new issue or same issue as here.

Also tried latest xdebug from master, same result as described here segfault 11 when xdebug is enabled and a breakpoint gets triggered.

I just tried adding "opcache.optimization_level=0xFFFFFBFF" to my local file /etc/opt/remi/php73/php.d/9999-last.ini and it worked for me.

Hi everybody,

this turned out to be a bug in PHP's OPcache extension: https://bugs.php.net/bug.php?id=77287 — a fix for this was committed today, and will make it into the next PHP release (PHP 7.3.2). I will leave this issue open and linked to the 2.7.0 release. I intend to release 2.7.0 soon after PHP 7.3.2 is released.

cheers,
Derick

I can confirm that I'm no longer seeing segfaults while xdebug is loaded and active after building from the latest PHP-7.3 branch containing that fix.

@mcfedr — It doesn't seem related. Please open a new issue, and make sure you make a gdb back trace, as the lldb one does not show any data. Alternative, please use valgrind to do memory analysis. There is a lot of information at https://xdebug.org/support.php#bugs that explain how to file a bug report in the most efficient way. (Once you've made it, I'll delete your comment and this one).

I've just committed a fix to Xdebug that implements a workaround for this. This will be part of the soon-to-be-released 2.7.0rc1.

opcache.optimization_level=0xFFFFFBFF helped also with problems on Debian with php7.3.1-1 and XDebug
Thanks.