Vscode-php-debug: XDebug Breakpoints Initially Ignored with Visual Studio Code over Docker

[deltoss]

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 " 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]

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]

@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]

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

[yogibear54]

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

[deltoss]

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]

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

[K0bin]

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]

Referencing https://github.com/Microsoft/vscode/issues/43959

[K0bin]

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]

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]

Everyone please try v1.12.2

[K0bin]

Works fine again.

[ddegasperi]

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]

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]

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]

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.