Similar reports here:
https://github.com/phalcon/cphalcon/issues/1969
https://gist.github.com/tony2001/3f08bfc9b1632ad630eb

Same with Xdebug v2.6.0-dev

Backtrace from current master branch:

• thread #1, stop reason = signal SIGSTOP
  • frame #0: 0x00007fff8a2f8b92 libsystem_c.dylibstrlen + 18 frame #1: 0x000000010d0b1111 php71strx_printv + 878
    frame 0000002: 0x000000010d0b22d7 php71ap_php_vsnprintf + 33 frame #3: 0x000000010df0fbdd xdebug.soxdebug_sprintf(fmt="$%s") at xdebug_str.c:97 [opt]
    frame 0000004: 0x000000010deff1aa xdebug.soxdebug_common_assign_dim_handler [inlined] xdebug_find_var_name(execute_data=0x000000010e01c4e0) at xdebug_code_coverage.c:179 [opt] frame #5: 0x000000010deff16e xdebug.soxdebug_common_assign_dim_handler(op=<unavailable>, do_cc=<unavailable>, execute_data=<unavailable>) at xdebug_code_coverage.c:343 [opt]
    frame 0000006: 0x000000010deff9ab xdebug.soxdebug_qm_assign_handler(execute_data=<unavailable>) at xdebug_code_coverage.c:395 [opt] frame #7: 0x000000010d1858b3 php71ZEND_USER_OPCODE_SPEC_HANDLER + 26
    frame 0000008: 0x000000010d142e9e php71execute_ex + 56 (lldb) frame select 4 xdebug.so was compiled with optimization - stepping may behave oddly; variables may not be available. frame #4: 0x000000010deff1aa xdebug.soxdebug_common_assign_dim_handler [inlined] xdebug_find_var_name(execute_data=0x000000010e01c4e0) at xdebug_code_coverage.c:179 [opt]
    176
    177 if (cur_opcode->opcode == ZEND_QM_ASSIGN) {
    178 #if PHP_VERSION_ID >= 70000
    -> 179 xdebug_str_add(&name, xdebug_sprintf("$%s", zend_get_compiled_variable_name(op_array, cur_opcode->result.var)->val), 1);
    180 #else
    181 xdebug_str_add(&name, xdebug_sprintf("$%s", zend_get_compiled_variable_name(op_array, cur_opcode->result.var, &cv_len)), 1);
    182 #endif
    (lldb) frame select 5
    frame 0000005: 0x000000010deff16e xdebug.soxdebug_common_assign_dim_handler(op=<unavailable>, do_cc=<unavailable>, execute_data=<unavailable>) at xdebug_code_coverage.c:343 [opt] 340 } 341 } 342 if (XG(do_trace) && XG(trace_context) && XG(collect_assignments)) { -> 343 full_varname = xdebug_find_var_name(execute_data TSRMLS_CC); (lldb) frame select 3 frame #3: 0x000000010df0fbdd xdebug.soxdebug_sprintf(fmt="$%s") at xdebug_str.c:97 [opt]
    94 int n;
    95
    96 va_start(args, fmt);
    -> 97 n = vsnprintf(new_str, size, fmt, args);
    98 va_end(args);
    99
    100 if (n > -1 && n < size) {
    (lldb) frame select 2
    frame 0000002: 0x000000010d0b22d7 php71ap_php_vsnprintf + 33 php71ap_php_vsnprintf:
    0x10d0b22d7 <+33>: movl (%rbx), %eax
    0x10d0b22d9 <+35>: addq $0x8, %rsp
    0x10d0b22dd <+39>: popq %rbx
    0x10d0b22de <+40>: popq %rbp

This is regression introduced in 5d611dfaa1351aa38b6744f31bedd2f137c882a5 commit. See this PR for more details: https://github.com/xdebug/xdebug/pull/363

I am going to need a small reproducible case here, or at the very least a reproducible case without any dependencies besides the code.

A small case shouldn't be very hard to make as tracing tells you exactly where in the code something crashes (or rather, it tells you which line was executed before the crash).

Simply making a trace (with xdebug.auto_trace=1, xdebug.collect_params=4, xdebug.collect_returns=1, xdebug.collect_assignments=1) should tell you the file/line combination, and hence, should allow you to find out a mimimal case.
As this seems to happen in reconstructing variable names, the pattern of the variable on each side of the QM_ASSIGN is going to be important.

I believe this is a duplicate of 0001474, which is fixed in the master branch on GitHub. Can you try that please?

Can't reproduce this, and no feedback provided.