View Issue Details

IDProjectCategoryView StatusLast Update
0001626XdebugStep Debuggingpublic2019-02-14 15:26
Reporterdeek Assigned Toderick  
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=&quot;/usr/local/Cellar/php/7.3.1/pecl/20180731/xdebug.so&quot;

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.
Attached Files
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 0000003: 0x0000000104a908de xdebug.soxdebug_dbgp_cmdloop + 350
      frame 0000004: 0x0000000104a91733 xdebug.soxdebug_dbgp_breakpoint + 819 frame 0000005: 0x0000000104a89b4d xdebug.soxdebug_statement_call + 781
      frame 0000006: 0x000000010037ab80 phpzend_llist_apply_with_argument + 31 frame 0000007: 0x00000001003feb95 phpZEND_EXT_STMT_SPEC_HANDLER + 47
      frame 0000008: 0x00000001003c0a8e phpexecute_ex + 98 frame 0000009: 0x0000000104a887f4 xdebug.soxdebug_execute_ex + 1332
      frame 0000010: 0x00000001003c0c0a phpzend_execute + 318 frame 0000011: 0x00000001003859fa phpzend_execute_scripts + 277
      frame 0000012: 0x000000010033142f phpphp_execute_script + 639 frame 0000013: 0x00000001004315b7 phpdo_cli + 3857
      frame 0000014: 0x0000000100430539 phpmain + 1234 frame 0000015: 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.

Issue History

Date Modified Username Field Change
2019-02-07 04:31 deek New Issue
2019-02-07 04:31 deek File Added: Screen Shot 2019-02-06 at 8.25.16 PM.png
2019-02-11 17:06 derick Relationship added has duplicate 0001627
2019-02-11 17:13 derick Note Added: 0004883
2019-02-11 17:13 derick Assigned To => derick
2019-02-11 17:13 derick Status new => feedback
2019-02-11 19:24 deek Note Added: 0004886
2019-02-11 19:24 deek Status feedback => assigned
2019-02-12 13:52 derick Note Added: 0004889
2019-02-12 13:52 derick Status assigned => feedback
2019-02-12 16:01 derick Note Added: 0004891
2019-02-12 16:01 derick Relationship added duplicate of 0001625
2019-02-12 16:01 derick Status feedback => resolved
2019-02-12 16:01 derick Resolution open => duplicate
2019-02-14 15:26 derick Relationship deleted has duplicate 0001627
2020-03-12 16:33 derick Category Remote Debugging => Step Debugging