View Issue Details

IDProjectCategoryView StatusLast Update
0001626XdebugRemote Debuggingpublic2019-02-14 15:26
ReporterdeekAssigned Toderick 
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionduplicate 
Platformx86_64OSMacOSOS Version10.14.2
Product Version2.7.0rc1 
Target VersionFixed in Version 
Summary0001626: Segmentation fault when superglobal query is run
DescriptionWhen 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

deek

2019-02-07 04:31

reporter  

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.so`xdebug_var_export_xml_node + 2647
xdebug.so`xdebug_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.so`xdebug_var_export_xml_node + 2647
    frame #1: 0x0000000104aa5174 xdebug.so`xdebug_get_zval_value_xml_node_ex + 308
    frame 0000002: 0x0000000104a93811 xdebug.so`xdebug_dbgp_handle_context_get + 1201
    frame 0000003: 0x0000000104a908de xdebug.so`xdebug_dbgp_cmdloop + 350
    frame 0000004: 0x0000000104a91733 xdebug.so`xdebug_dbgp_breakpoint + 819
    frame 0000005: 0x0000000104a89b4d xdebug.so`xdebug_statement_call + 781
    frame 0000006: 0x000000010037ab80 php`zend_llist_apply_with_argument + 31
    frame 0000007: 0x00000001003feb95 php`ZEND_EXT_STMT_SPEC_HANDLER + 47
    frame 0000008: 0x00000001003c0a8e php`execute_ex + 98
    frame 0000009: 0x0000000104a887f4 xdebug.so`xdebug_execute_ex + 1332
    frame 0000010: 0x00000001003c0c0a php`zend_execute + 318
    frame 0000011: 0x00000001003859fa php`zend_execute_scripts + 277
    frame 0000012: 0x000000010033142f php`php_execute_script + 639
    frame 0000013: 0x00000001004315b7 php`do_cli + 3857
    frame 0000014: 0x0000000100430539 php`main + 1234
    frame 0000015: 0x00007fff60ce0ed9 libdyld.dylib`start + 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