View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0001626XdebugStep Debuggingpublic2019-02-07 04:312019-02-14 15:26
Reporterdeek Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionduplicate 
Platformx86_64OSMacOSOS Version10.14.2
Product Version2.7.0rc1 
Summary0001626: Segmentation fault when superglobal query is run
Description

When trying to debug a local script a segmentation faults would occur. After pairing down the code I was able to make the segmentation fault occur at multiple locations. The simplest case is below. I believe it is similar to ticket 1625

Steps To Reproduce

xdebugTest.php

<?php

$clientID = 1234;
$clientName = "Test Client"; // Breakpoint

When running the test file it would correctly enter the breakpoint. However if you click on the Superglobals in the VS Code debugger it will generate a segmentation fault

segmentation fault php -d zend_extension="/usr/local/Cellar/php/7.3.1/pecl/20180731/xdebug.so"

Additional Information
  • Visual Studio Code, 1.30.2
  • PHP 7.3.1 (Homebrew)

PHP 7.3.1 (cli) (built: Jan 10 2019 13:15:37) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.1, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.1, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v2.7.0rc1, Copyright (c) 2002-2019, by Derick Rethans

  • I was unable to generate a gdb call stack
    (gdb) run
    Starting program: /usr/local/bin/php -d zend_extension=/usr/local/Cellar/php/7.3.1/pecl/20180731/xdebug.so xdebugTest.php
    [New Thread 0xa07 of process 66806]
    [New Thread 0x1603 of process 66806]
    During startup program terminated with signal SIGTRAP, Trace/breakpoint trap.
  • I was unable to generate a valgrind as it is not available for 10.14 yet
TagsNo tags attached.
Operating SystemMacOS
PHP Version7.3.0-7.3.1

Relationships

duplicate of 0001625 closedderick Work around ABI conflicts in PHP 7.3.0/PHP 7.3.1 

Activities

derick

2019-02-11 17:13

administrator   ~0004883

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

deek

2019-02-11 19:24

reporter   ~0004886

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?

derick

2019-02-12 13:52

administrator   ~0004889

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

derick

2019-02-12 16:01

administrator   ~0004891

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.