Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension seems to be ignoring breakpoints #242

Closed
NerijusNoreika opened this issue Feb 22, 2018 · 12 comments
Closed

Extension seems to be ignoring breakpoints #242

NerijusNoreika opened this issue Feb 22, 2018 · 12 comments

Comments

@NerijusNoreika
Copy link

NerijusNoreika commented Feb 22, 2018

PHP version: 7.0.23
XDebug version: 2.4.0
Adapter version: 1.12.1

Your launch.json:

 {
            "name": "Enenos",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "pathMappings": {
                "/html/erenos/public": "${workspaceRoot}/Enenos/public",                
            },
            "log": true
 }

XDebug php.ini config:

zend_extension=/usr/local/php/ext/xdebug.so
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
xdebug.remote_log = /tmp/xdebug.log

XDebug logfile (from setting xdebug.remote_log in php.ini):

I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to 46.30.62.43:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///html/erenos/public/index.php" language="PHP" xdebug:language_version="7.0.23" protocol_version="1.0" appid="14950"><engine version="2
.4.0"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2016 by Derick Rethans]]></copyright></init>

-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" status="stopping" reason="ok"></response>
Log closed at 2018-02-22 13:10:04

Adapter logfile (from setting "log": true in launch.json):
<- launchResponse
Response {
seq: 0,
type: 'response',
request_seq: 2,
command: 'launch',
success: true }

Code snippet to reproduce:

print 'Hello World<br>';
function init() {
    print 'hello world';
}
print 'It is working';
phpinfo();

Testing xdebug for remote host debugging. It seems like xdebug is getting the connection, however on vscode side nothing at all.

I thought maybe absolute path is needed for local files(i've read some issues here), but that doesn't help in this case.

@hgouveia
Copy link

i've exactly same issue with same output

@deltoss
Copy link

deltoss commented Feb 23, 2018

Did you check if other types of breakpoint works, i.e. putting in "xdebug_break()", or runtime errors.

@NerijusNoreika
Copy link
Author

@oniisaki
Yes, tried xdebug_break() nothing changes. I am thinking perhaps I should lower PHP version, because heard that 2.4~ gets some hiccups with PHP7. Will try and see what comes of it.

@hgouveia
Copy link

@oniisaki for me xdebug_break() worked, but the breakpoint on VSCode are ignored anyway, i don't believe is the PHP version im using PHP7.1 and that's the one i've been using before when it worked

also using "stopOnEntry": true, on the launch.json kind of work, but for some reason, some breakpoints are ignored and others do break

@patrik-martinko
Copy link

It's because of VS Code v1.20.x. This update broke the functionality of Xdebug plugin. Try to downgrade to v1.19 (https://code.visualstudio.com/updates/v1_19)

@benriga
Copy link

benriga commented Feb 25, 2018

I'm having issues with this also. I've rolled back to VS Cdoe 1.19.3 but my breakpoints are still not triggering. I do see VS breaking on exceptions but breakpoints are not happening.

Is there a special way to rollback VSC? Do I have to uninstall first or something?

Edit: I finally figured out that some of the changes to my launch.json that I had made when trying to get 1.20 to work do not work with 1.19. Putting this here in case it helps someone else.

Specifically I had changed pathMapping to use an absolute path. Changing it back to ${workspaceFolder} got me my breakpoints back.

    "pathMappings": {
      "/app/public": "${workspaceFolder}",
      // "/app/public": "C:/Users/Ben/Local Sites/mysite/app/public",
    },

@NerijusNoreika
Copy link
Author

NerijusNoreika commented Feb 26, 2018

Hey guys, I've managed to make it work properly.

For some reason, even though logs show that the connection was successful, it does not connect properly. My solution was port forward with ssh:

ssh -R 9000:localhost:9000 your-host-name@your-host-server

I don't know why I need to port forward to the same port, but hey it works...

Then it connects for both 1.20 and 1.19 BUT 1.20 ignores breakpoints all together - only possible to trigger debugging by including xdebug_break() in the code itself.

1.19 works perfectly :) (tested on 1.19.1)

@hidekuro
Copy link

hidekuro commented Feb 26, 2018

I found a clue for the solution.

at first, ${workspaceRoot} is DEPRECATED in VSCode1.20.x.
use ${workspaceFolder} instead of it!

in my case:

  • develop Laravel app with vagrant on windows10.
  • C:\Users\hidekuro\git\myapp is Laravel 5.5 app project root.
  • C:\Users\hidekuro\git\myapp mount to /vagrant in VM.
  • php7.2.2 (both of host os and VM)
; xdebug settings
zend_extension=xdebug.so
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
xdebug.remote_log = /vagrant/xdebug.log

pathMappings and the behavior patterns are as follows.

  • "/vagrant": "${workspaceRoot}" // DEPRECATED.
  • "/vagrant": "${workspaceFolder}" // recommended but not work.
  • "/vagrant": "C:\\Users\\hidekuro\\git\\myapp" // not work. (UPPER drive letter)
  • "/vagrant": "c:\\Users\\hidekuro\\git\\myapp" // it works! (LOWER drive letter and directory separated by escaped backslash)
  • "/vagrant": "c:/Users/hidekuro/git/myapp" // it works too! (LOWER drive letter and directory separated by slash)
  • "/vagrant": "c:/Users\\hidekuro\\git/myapp" // it works too! (LOWER drive letter and directory separated by slash + backslash mixed.)

in worked case, php file url in xdebug log is start with "file:///vagrant/...". it's correct file url in VM.

<- breakpoint_set -i 2 -t line -f file:///vagrant/app/Http/Controllers/HelloController.php -n 25

and not worked case ( "/vagrant": "${workspaceFolder}" ), start with "c:/Users/...". it's incorrect in VM.

<- breakpoint_set -i 2 -t line -f c:/Users/hidekuro/git/myapp/app/Http/Controllers/HelloController.php -n 25

I hope this becomes a hint to solve problem.

I want to sharing workspace wide launch.json in team.
but can't it. because currently absolute path required in pathMapping to debug correctly.

@hidekuro
Copy link

hidekuro commented Feb 26, 2018

TL;DR the workaround for windows users

  • Write pathMappings with absolute path using lower drive letter and slashes. (Other than drive letters, case sensitive.)

ex)

"pathMappings": {
    "/vagrant": "c:/Users/YourName/path/to/proj"
}

@hidekuro
Copy link

FYI. microsoft/vscode#43959

@NerijusNoreika
Copy link
Author

I will close the issue, because the solution is known and the bug is not coming from xdebug extension.

@ubthung
Copy link

ubthung commented Jul 19, 2018

@oniisaki for me xdebug_break() worked, but the breakpoint on VSCode are ignored anyway, i don't believe is the PHP version im using PHP7.1 and that's the one i've been using before when it worked
also using "stopOnEntry": true, on the launch.json kind of work, but for some reason, some breakpoints are ignored and others do break

Now I have solution for this case.
Follow steps bellow:

  1. You need add xdebug_break() somewhere in your code (maybe the first line of function you want to debug).
  2. When the app stopping at xdebug_break(), now you can add any breakpoint you want, and press F5 (continue), the app will stop at next breakpoint.

Tested on host (Window 10, VSCode 1.12.1) and remoted server (Vagrant, Laravel Homestead, PHP 7.2.4, Xdebug 2.6.0)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants