xdebugTest.php

Hi,

thanks for this report. I can unfortunately not reproduce this. When locally the context_get -c 1 is run (for Superglobals) I get a right answer, and valgrind is silent too. It's a pity that GDB didn't produce anything useful, as it would have been really handy right now. I don't have a mac to try myself either.

From https://stackoverflow.com/questions/49001329/gdb-doesnt-work-on-macos-high-sierra-10-13-3 it seems that your gdb is too new, and you might need to downgrade to 8.0.1 — and that link also suggest that you temporarily turn off SIP as is described at https://www.imore.com/how-turn-system-integrity-protection-macos

Would you please mind trying these things?

cheers,
Derick

Hello,

I've tried a few things, including the links provided, with gdb without much success. I was however able to get something to trigger using lldb.

Process 39156 stopped

• thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  frame #0: 0x0000000104aa5e27 xdebug.soxdebug_var_export_xml_node + 2647 xdebug.soxdebug_var_export_xml_node:
  -> 0x104aa5e27 <+2647>: callq *(%rax)
  0x104aa5e29 <+2649>: movq %rax, -0x70(%rbp)
  0x104aa5e2d <+2653>: movq 0x10(%r15), %rsi
  0x104aa5e31 <+2657>: movq -0x30(%rbp), %rdi
  Target 0: (php) stopped.
  (lldb) bt
• thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  • frame #0: 0x0000000104aa5e27 xdebug.soxdebug_var_export_xml_node + 2647 frame #1: 0x0000000104aa5174 xdebug.soxdebug_get_zval_value_xml_node_ex + 308
    frame 0000002: 0x0000000104a93811 xdebug.soxdebug_dbgp_handle_context_get + 1201 frame #3: 0x0000000104a908de xdebug.soxdebug_dbgp_cmdloop + 350
    frame 0000004: 0x0000000104a91733 xdebug.soxdebug_dbgp_breakpoint + 819 frame #5: 0x0000000104a89b4d xdebug.soxdebug_statement_call + 781
    frame 0000006: 0x000000010037ab80 phpzend_llist_apply_with_argument + 31 frame #7: 0x00000001003feb95 phpZEND_EXT_STMT_SPEC_HANDLER + 47
    frame 0000008: 0x00000001003c0a8e phpexecute_ex + 98 frame #9: 0x0000000104a887f4 xdebug.soxdebug_execute_ex + 1332
    frame 0000010: 0x00000001003c0c0a phpzend_execute + 318 frame #11: 0x00000001003859fa phpzend_execute_scripts + 277
    frame 0000012: 0x000000010033142f phpphp_execute_script + 639 frame #13: 0x00000001004315b7 phpdo_cli + 3857
    frame 0000014: 0x0000000100430539 phpmain + 1234 frame #15: 0x00007fff60ce0ed9 libdyld.dylibstart + 1
    frame 0000016: 0x00007fff60ce0ed9 libdyld.dylib`start + 1

Is this helpful? I will continue to look into getting gdb working since that seems to be the main debugger being used.

Is there any additional logging I can turn on for local debugging?

Hi deek,

that's a bit closer. It's possible that because there are no debugging symbols, we don't get to see the exact line and arguments. As I don't have access to OSX, and never have used lldb, it is a bit tricky for me to suggest how to do debug this.

The following might do the trick:

cd /tmp (or any other tmp directory)
pecl download xdebug-beta
tar -xvzf xdebug-2.7.0RC1.tgz
cd xdebug-2.7.0RC1/
phpize
./configure --enable-xdebug-dev
make && make install

(this does nearly the same as PECL would do, but adds the --enable-xdebug-dev options that add debugging symbols to xdebug).

Then try triggering the issue with lldb again. It hopefully shows more information. On the lldb prompt, perhaps you can do:

show values in the current stack frame:

frame variable

And do that for frame 1 and 2 too:

frame 1
frame variable
frame info
frame 2
frame variable
frame info

This is very likely a duplicate of 0001625, which has a better back trace and information including source lines. I'm merging this bug with 0001625, so please add your comments to that one.

I'm closing this out as "duplicate" for now.