martomo / SublimeTextXdebug

Xdebug debugger client for Sublime Text
MIT License
564 stars 89 forks source link

No debugging actions upon session start #194

Closed Daniel-Yonkov closed 4 years ago

Daniel-Yonkov commented 5 years ago

Upon starting debugging I am unable to run any of the commands in navigating the debugging screens. (Run, step_ver, step_into etc...). The debugging stops at the breakpoint and it's unable to continue by any means. Using the command Xdebug: Session execute - to execute xdebug_continue the debugging process ends. With the current configuration, I have tried with NetBeans and the debugging works correctly. I am not sure if the configuration is the issue or plugin issue. Please if possible advice.

P.S. The path mapping is being used since if I map the same folder even though is local http server, I do not trigger debugging, the folder is a symlink to the one within the nginx shared folder. (usr/share/nginx/html/patterns/)

image

Environment

Sublime Text

Operating system: Linux - 4.19.24-1-MANJARO Installed version/build: 3.1.1 Python version: 3.7.3

Server

Operating system: local server, same as sublime text environment (using nginx as web server).

Are you trying to debug the script remotely or locally? - locally

PHP/Xdebug version: v2.7.0RC2

Configuration

php.ini/xdebug.ini

zend_extension=/usr/lib/php/modules/xdebug.so
xdebug.remote_enable=on
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9002
xdebug.remote_handler=dbgp
xdebug.remote_mode = req
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
xdebug.idekey = sublime.xdebug
xdebug.remote_log = /home/dippy/logs/php/xdebug.log
xdebug.profiler_enable = on
xdebug.profiler_enable_trigger = on

Packages/User/Xdebug.sublime-settings

{
    "path_mapping": {
        "/usr/share/nginx/html/patterns" : "/home/dippy/Tutorials/patterns",
        "url": "http://dev.patterns.com/",
        "port": 9002,
        "super_globals": false,
    },
}
makomination commented 5 years ago

I have the same issue. Also using nginx & php7.3.3

makomination commented 5 years ago

I've tried the built-in web server of php 7.3.3, but stil have the same issue. I guess php 7.3.3 is a cause of the issue.

Daniel-Yonkov commented 5 years ago

Any recommendation on what version to downgrade for latest support of this plugin?

On Fri, Mar 15, 2019, 20:08 makomination notifications@github.com wrote:

I've tried the built-in web server of php 7.3.3, but stil have the same issue. I guess php 7.3.3 is a cause of the issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/martomo/SublimeTextXdebug/issues/194#issuecomment-473389279, or mute the thread https://github.com/notifications/unsubscribe-auth/AUDRpisBtj2YnEWbb-eJKpBJ70TnhGdeks5vW-GAgaJpZM4bjfxD .

makomination commented 5 years ago

@Daniel-Yonkov I've downgraded PHP 7.3.3 to 7.1.26 and Xdebug 2.7.0 to 2.5.5. Now all working fine :)

meengit commented 5 years ago

We have these settings running in our development team. Xdebug >= 2.6 & php >= 7.1

Environment: Vagrant VM or Docker, eg. DrupalVM

Xdebug Config:

zend_extension="/usr/lib/php/7.1/modules/xdebug-2.6.0.so"
xdebug.remote_enable=1
xdebug.remote_host=10.0.X.Y # default gateway
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.idekey=""
xdebug.remote_log=/tmp/xdebug.log
xdebug.coverage_enable=0

xdebug.default_enable=1
xdebug.max_nesting_level=256

SublimeText Project settings:

{
  "settings": {
    "xdebug": {
    "path_mapping": {
      "/remote/path/to/project" : "/local/path/to/project"
    },
    "port": 9000,
    "debug": true,
    "break_on_start": false,
    "super_globals": true,
    "close_on_stop": true
    }
  }
}

I know, in some cases its not 100% "best practice" but it works.

Daniel-Yonkov commented 5 years ago

We have these settings running in our development team. Xdebug >= 2.6 & php >= 7.1

Environment: Vagrant VM or Docker, eg. DrupalVM

Xdebug Config:

zend_extension="/usr/lib/php/7.1/modules/xdebug-2.6.0.so"
xdebug.remote_enable=1
xdebug.remote_host=10.0.X.Y # default gateway
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=1
xdebug.idekey=""
xdebug.remote_log=/tmp/xdebug.log
xdebug.coverage_enable=0

xdebug.default_enable=1
xdebug.max_nesting_level=256

SublimeText Project settings:

{
  "settings": {
    "xdebug": {
    "path_mapping": {
      "/remote/path/to/project" : "/local/path/to/project"
    },
    "port": 9000,
    "debug": true,
    "break_on_start": false,
    "super_globals": true,
    "close_on_stop": true
    }
  }
}

I know, in some cases its not 100% "best practice" but it works.

@meengit which Python version is being used in that VM?

meengit commented 5 years ago

@Daniel-Yonkov, Python 2.7.12

However, I think it doesn't matter. (Sublime is running locally and Xdebug remotely.) I have Docker containers running without Python where these settings work.

I usually advise the folks of my team to use my fork of this repository and then it works:

cmd+shift+p > "Package Control: Remove Package Xdebug Client"

Then:

cd ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/
git clone https://github.com/meengit/SublimeTextXdebug.git "Xdebug Client"

& Sublime restart …

juangiordana commented 5 years ago

@meengit, your comment made my day. Thanks!

This is a copy of what I did to have Xdebug working with Sublime Text running in a Windows 10 box.

https://gist.github.com/juangiordana/3cf4905545b0230a43bce118896b77bb

Daniel-Yonkov commented 5 years ago

@meengit @juangiordana - Still no continuation commands, I have identical build, even testing it on windows machine, Though I can see the superglobals, which is a good fix, I still cannot navigate throughout the code, only staying at the state of the breakpoint: right click menu toolbar menu

alexkuc commented 5 years ago

I encountered the same issue and the fork provided by @gepeixoto worked for me

keldrox commented 5 years ago

@Daniel-Yonkov Did you solve the problem? The same thing happens to me

Environment

Sublime Text 3.2.1 build 3207 Operating system: Windows - 10 PRO

Server

Operating system: Linux Docker witch Devilbox

Are you trying to debug the script remotely or locally? - locally

PHP/Xdebug version: v2.7.2

Configuration

php.ini/xdebug.ini

xdebug.default_enable   = On
xdebug.profiler_enable  = On
xdebug.remote_enable    = On
xdebug.remote_autostart = On
xdebug.remote_connect_back=0
xdebug.remote_host=192.168.27.161
xdebug.remote_handler   = dbgp
xdebug.remote_port      = 9000
xdebug.idekey           = sublime.xdebug
xdebug.remote_log       = /var/log/php/xdebug.log

Packages/User/Xdebug.sublime-settings

{
    "path_mapping": {
        "/shared/httpd" : "C:\\devilbox\\data\\www"
    },
    "url": "",
    "ide_key": "sublime.xdebug",
    "host": "0.0.0.0",
    "port": 9000,
    "super_globals": false,
    "close_on_stop": true,
    "max_children": 4096, 
    "max_data": 268435456,
    "max_depth": 1 
}
Daniel-Yonkov commented 5 years ago

@keldrox - Sadly no, as mentioned previously @alexkuc - the fix by @gepeixoto works, but I noticed an exponentian increase of the delay on the parsing of the data.

gepeixoto commented 5 years ago

@keldrox - Sadly no, as mentioned previously @alexkuc - the fix by @gepeixoto works, but I noticed an exponentian increase of the delay on the parsing of the data.

Surely, the increase of the delay has nothing to do with the fix I provided, because it basically fix the URL for the xdebug server (https). So, I think the delay is from the xdebug server.

Daniel-Yonkov commented 5 years ago

@gepeixoto - I thought it maybe the case, which I later on tested both the release branch and @meengit branch, both of them work as expected in relation to speed (though lacking the action context upon session start). Also tested a NetBeans Xdebug Client in order to verify is not a server delay and actually it worked as fast as the sublime plugin in relation to speed. Which is why I believe is something to do with the parsing of the xml.

martomo commented 4 years ago

Closing this issue as this should be resolved with release 1.1.2, in case the issue was not resolved please let me know.