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

XDebug Breakpoints Initially Ignored with Visual Studio Code over Docker #240

Closed
deltoss opened this issue Feb 16, 2018 · 18 comments
Closed
Labels
remote debugging All issues related to debugging a remote host (server, VM, Docker container, ...)

Comments

@deltoss
Copy link

deltoss commented Feb 16, 2018

The Issue

Followed the instructions outlined in the below link to get docker working with Visual Studio Code.
Setting Up and Debugging PHP7 in Docker

I followed the above tutorial using:
• PHP version 7.0.17
• XDebug 2.5.5
• VS Code 1.20.1
• PHP Debug 1.12.1.
The issue is the Visual Studio Code doesn’t seem to function correctly with XDebug over Docker. Any breakpoints added are ignored.

The strange thing is the breakpoints would behave and trigger correctly after XDebug halts the code execution from:
• Hitting a “xdebug_break();” PHP line, which programmatically creates a breakpoint
• Intentionally make a run-time error (such as a call for a non-existing function, or divide by zero error), which causes a breakpoint to where the exception occurred
However, this is inconvenient, as the above to happen would always need to happen before breakpoints could be used normally per debugging session.

What I've Tried so Far

• I tried upgrading to the latest PHP version 7.2.2 with XDebug Version 2.6.0, and still had the same issue.
• I’ve made sure XDebug was installed correctly through "<php? phpinfo() ?> and XDebug Wizard (https://xdebug.org/wizard.php)
• It seems like the PHP Debug is connecting to XDebug correctly, as shown in below logs, however breakpoints aren’t triggering
• Tried WAMP to see if this issue also happens there, but its behaving fine
• Checked with Notepad++ with DBGP plugin to work with XDebug using NotePad++. It actually worked fine with the Docker setup.

Basically, this issue seems to only occur with VSCode and PHPDebug with Docker?

Logs

My Launch.Json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "pathMappings": {
                "/var/www/html": "${workspaceRoot}/htdocs"
            },
            "port": 9000,
            "log": true
        },
    ]
}

XDebug php.ini config:

[xdebug]
zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20151012/xdebug.so
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.remove_connect_back=0
; The IP pointing to the client machine's IP Address you are DEBUGGING with
xdebug.remote_host=10.0.75.1
xdebug.remote_port=9000
xdebug.remote_log=/tmp/xdebug_log/xdebug.log

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

Log opened at 2018-02-16 03:14:37
I: Connecting to configured address/port: 10.0.75.1:9000.
I: Connected to client. :-)
-> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/index.php" language="PHP" xdebug:language_version="7.2.2" protocol_version="1.0" appid="16"><engine version="2.6.0"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[http://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2018 by Derick Rethans]]></copyright></init>

<- breakpoint_list -i 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="1"></response>

<- breakpoint_set -i 2 -t line -f file:///c:/php7-apache2-docker-master-original/htdocs/index.php -n 2
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="2" id="160019"></response>

<- breakpoint_list -i 3
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="3"><breakpoint type="line" filename="file:///c:/php7-apache2-docker-master-original/htdocs/index.php" lineno="2" state="enabled" hit_count="0" hit_value="0" id="160019"></breakpoint></response>

<- breakpoint_list -i 4
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="4"><breakpoint type="line" filename="file:///c:/php7-apache2-docker-master-original/htdocs/index.php" lineno="2" state="enabled" hit_count="0" hit_value="0" id="160019"></breakpoint></response>

<- breakpoint_set -i 5 -t exception -x Notice
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="5" id="160020"></response>

<- breakpoint_set -i 6 -t exception -x Warning
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="6" id="160021"></response>

<- breakpoint_set -i 7 -t exception -x Error
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="7" id="160022"></response>

<- breakpoint_set -i 8 -t exception -x Exception
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="8" id="160023"></response>

<- breakpoint_set -i 9 -t exception -x *
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="9" id="160024"></response>

<- run -i 10
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="run" transaction_id="10" status="stopping" reason="ok"></response>

<- stop -i 11
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="stop" transaction_id="11" status="stopped" reason="ok"></response>

Log closed at 2018-02-16 03:14:37

Adapter logfile (from setting "log": true in launch.json):

<- launchResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 2,
  command: 'launch',
  success: true }

new connection 1
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'started', threadId: 1 } }

<- initializedEvent
InitializedEvent { seq: 0, type: 'event', event: 'initialized' }

-> threadsRequest
{ command: 'threads', type: 'request', seq: 3 }

<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 3,
  command: 'threads',
  success: true,
  body: { threads: [ Thread { id: 1, name: 'Request 1 (14:14:37)' } ] } }

-> setBreakpointsRequest
{ command: 'setBreakpoints',
  arguments: 
   { source: 
      { name: 'index.php',
        path: 'c:\\php7-apache2-docker-master-original\\htdocs\\index.php' },
     lines: [ 2 ],
     breakpoints: [ { line: 2 } ],
     sourceModified: false },
  type: 'request',
  seq: 4 }

<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 4,
  command: 'setBreakpoints',
  success: true,
  body: { breakpoints: [ { verified: true, line: 2 } ] } }

-> setFunctionBreakpointsRequest
{ command: 'setFunctionBreakpoints',
  arguments: { breakpoints: [] },
  type: 'request',
  seq: 5 }

<- setFunctionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 5,
  command: 'setFunctionBreakpoints',
  success: true,
  body: { breakpoints: [] } }

-> setExceptionBreakpointsRequest
{ command: 'setExceptionBreakpoints',
  arguments: { filters: [ 'Notice', 'Warning', 'Error', 'Exception', '*' ] },
  type: 'request',
  seq: 6 }

<- setExceptionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 6,
  command: 'setExceptionBreakpoints',
  success: true }

-> configurationDoneRequest
{ command: 'configurationDone', type: 'request', seq: 7 }

-> threadsRequest
{ command: 'threads', type: 'request', seq: 8 }

<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 8,
  command: 'threads',
  success: true,
  body: { threads: [ Thread { id: 1, name: 'Request 1 (14:14:37)' } ] } }

<- configurationDoneResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 7,
  command: 'configurationDone',
  success: true }

<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'exited', threadId: 1 } }
@serl
Copy link

serl commented Feb 16, 2018

Same issue here!

A workaround seems to be putting the absolute path instead of ${workspaceRoot}, as in:

      "pathMappings": {
        // "/var/www/html": "${workspaceRoot}"
        "/var/www/html": "c:/Users/path/to/project"
      }

And of course stopping/starting the debugger....

@deltoss
Copy link
Author

deltoss commented Feb 16, 2018

@serl Switching to absolute paths works!

I read that ${workspaceRoot} is deprecated, so I tried switching to the updated environment variable ${workspaceFolder} to see if it works, but that was still no good.

How curious...I wonder what value was ${workspaceRoot} or ${workspaceFolder} giving me?

@felixfbecker
Copy link
Contributor

Did anyone raise this issue at the vscode repo? It doesn't seem like this is a bug in the extension

@yogibear54
Copy link

Thanks @serl ! Yes, with the absolute path set, it works for me too!!!! Finally, now back up to the latest version of vscode :)

@deltoss
Copy link
Author

deltoss commented Feb 23, 2018

From the post made by @kestrelhawk from the above referenced issue, it sounds like PHP Debug uses lower-case drive letters. VS Code $(workspaceFolder) gives upper-case drive letters. So there's a mismatch in casing.

Why does PHP Debug need to use lower-case drive letters for path mappings?
Is it not possible to use upper case, or at least throw an error when the user try to use upper case drive letters in the path mappings, since it won't even function correctly anyway.

@felixfbecker
Copy link
Contributor

felixfbecker commented Feb 23, 2018

Feel free to do a PR. The adapter doesn't enforce lowercase drive letters, but I think XDebug does.

@felixfbecker felixfbecker added the remote debugging All issues related to debugging a remote host (server, VM, Docker container, ...) label Feb 23, 2018
@K0bin
Copy link

K0bin commented Mar 8, 2018

It seems VS Code 1.21 changes the drive letter to upper case even when using hard coded paths.

The extension is using upper case drive letters for setBreakpointsRequest even though my pathMapping has a lower case one. The mapping itself isn't the problem because xdebug_break() works fine.

@felixfbecker
Copy link
Contributor

Referencing microsoft/vscode#43959

@K0bin
Copy link

K0bin commented Mar 8, 2018

To be honest, I don't get the point of reporting that over there. It's working fine on the VS Code side of things, Windows drive letters are generally upper case. If XDebug is the one that has issues with this, the obvious fix would be to just change it to lowercase before sending requests.

Just like #245 and #198 do.

@orjhor
Copy link

orjhor commented Mar 15, 2018

I'm having the same issue with not being able to step into/over breakpoints, the only option to proceed executing code is to stop the debugger. I'm on PHP 7.1.15 NTS and VS Code 1.21.1.

A workaround seems to be putting the absolute path instead of ${workspaceRoot}

Unfortunatly, this workaround does not work for me. See my launch.json below:

`{
"version": "0.2.0",
"configurations": [

    {
        "name": "Listen for XDebug",
        "type": "php",
        "request": "launch",
        "port": 9000,
        "pathMappings": {
            "/var/www/html": "d:/code/Wordpress"
        },
    }
]

}`

edit: I'm not using Docker though

edit 2: The tip by @chriswatt in #150 helped me solve the issue

@felixfbecker
Copy link
Contributor

Everyone please try v1.12.2

@K0bin
Copy link

K0bin commented Mar 15, 2018

Works fine again.

@ddegasperi
Copy link

I've had problems with using ${workspaceFolder} too. (on macos high sierra). I've solved the problem removing the slash between the variable and the folder name:

Example:

Not working: "/app": "${workspaceFolder}/site"

Working: "/app": "${workspaceFolder}site"

@danLDev
Copy link

danLDev commented Aug 12, 2020

Had this issue but only when setting breakpoints on certain files (exactly which files would/wouldn't work was changing when re-starting vscode).

After some digging this was caused by the watcher limit, resolved as per
https://code.visualstudio.com/docs/setup/linux#_visual-studio-code-is-unable-to-watch-for-file-changes-in-this-large-workspace-error-enospc

@JPustkuchen
Copy link

JPustkuchen commented Jan 21, 2021

I've had problems with using ${workspaceFolder} too. (on macos high sierra). I've solved the problem removing the slash between the variable and the folder name:

Example:

Not working: "/app": "${workspaceFolder}/site"

Working: "/app": "${workspaceFolder}site"

@ddegasperi
Did you try

"pathMappings": {
        "/app/": "${workspaceFolder}/",
      }
    }

? Does that work?

@adjenks
Copy link

adjenks commented Mar 27, 2021

I tried everything described in here, I still can't set breakpoints. Instead I just write some invalid code where I want to stop now.

@stevenseeley
Copy link

      "pathMappings": {
        // "/var/www/html": "${workspaceRoot}"
        "/var/www/html": "c:/Users/path/to/project"
      }

dude, thank you, this is amazing!

@lukastom
Copy link

lukastom commented Apr 29, 2023

@felixfbecker This still does not work on Docker 23.0.5, Linux Mint 21.1, VSCode 1.77.3, XDebug 3.2.1. Instead of &{workspaceFolder}, I had to use /home/user/Sites/php-app/src/.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
remote debugging All issues related to debugging a remote host (server, VM, Docker container, ...)
Projects
None yet
Development

No branches or pull requests