XDebugError: command is not available

[MarceloLuis1997]

Hi,

I'm using this awesome extension for a while and sometimes in the Debug Console it shows the error XDebugError: command is not available. The debug still works fine after that, but the Debug Console often shows that error.

PHP version: 7.4.3
XDebug version: 2.9.6-7.4
Adapter version: v1.14.5

launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000
        },
        {
            "name": "Launch currently open script",
            "type": "php",
            "request": "launch",
            "program": "${file}",
            "cwd": "${fileDirname}",
            "port": 9000
        }
    ]
}

XDebug php.ini config:

zend_extension = C:\xampp\php\ext\php_xdebug-2.9.6-7.4-vc15-x86_64.dll
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_host = localhost
xdebug.remote_handler=dbgp
xdebug.remote_port = 9000

Error log:

connection 342: read ECONNRESET
XDebugError: command is not available
    at new Response (c:\Users\Marcelo\.vscode\extensions\felixfbecker.php-debug-1.14.5\out\xdebugConnection.js:58:19)
    at Connection.<anonymous> (c:\Users\Marcelo\.vscode\extensions\felixfbecker.php-debug-1.14.5\out\xdebugConnection.js:613:20)
    at Generator.next (<anonymous>)
    at fulfilled (c:\Users\Marcelo\.vscode\extensions\felixfbecker.php-debug-1.14.5\out\xdebugConnection.js:5:58)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:94:5) {
  code: 5,
  name: 'XDebugError'
}
connection 363: read ECONNRESET

Code snippet to reproduce: It just randomly shows the error in any endpoint of my laravel application.

[allanwolski]

Same problem here with my Zend application.

PHP version: 7.1.24
XDebug version: 2.9.8-7.1
Adapter version: v1.14.5

XDebugError: command is not available
    at new Response (c:\Users\Allan\.vscode\extensions\felixfbecker.php-debug-1.14.5\out\xdebugConnection.js:58:19)
    at Connection.<anonymous> (c:\Users\Allan\.vscode\extensions\felixfbecker.php-debug-1.14.5\out\xdebugConnection.js:613:20)
    at Generator.next (<anonymous>)
    at fulfilled (c:\Users\Allan\.vscode\extensions\felixfbecker.php-debug-1.14.5\out\xdebugConnection.js:5:58)
    at processTicksAndRejections (internal/process/task_queues.js:94:5) {
  code: 5,
  name: 'XDebugError'
}

[wellu]

Happens here also. Sometimes I need to restart debugging session to get over it. Sometimes I restart whole Visual Studio too. Dunno what causes this.

[zobo]

If I could see the dbgp log (xdebug3 https://xdebug.org/docs/all_settings#log xdebug2 https://2.xdebug.org/docs/all_settings#remote_log) it would help.
The error here comes from Xdebug. The trace shows it happens in response to sendBreakpointRemoveCommand that only happens when VSC is setting breakpoints.

The dbgp error is described here: https://xdebug.org/docs/dbgp#error-codes and the code (Xdebug branch 2.9) gets created here https://github.com/xdebug/xdebug/blob/12ffd358e6c566788b84c409bd77584a67ad8755/src/debugger/handler_dbgp.c

This tells me, that VSC + adapter are sending breakpoint_remove command when the script is in stopping state.

[R0Wi]

Hi all, i'm using a docker image to run apache with xdebug 3 (https://github.com/thecodingmachine/docker-images-php). In general my setup seems to work since some breakpoints work correctly. Although others do not. I tested the setup by trying to debug Nextcloud so i set one breakpoint here which works and another one here which does not seem to work since the debugger doesn't break and instead prints the following error messages onto the console:

XDebugError: no such breakpoint
    at new Response (/home/robin/.vscode/extensions/felixfbecker.php-debug-1.14.5/out/xdebugConnection.js:58:19)
    at Connection.<anonymous> (/home/robin/.vscode/extensions/felixfbecker.php-debug-1.14.5/out/xdebugConnection.js:613:20)
    at Generator.next (<anonymous>)
    at fulfilled (/home/robin/.vscode/extensions/felixfbecker.php-debug-1.14.5/out/xdebugConnection.js:5:58)
    at processTicksAndRejections (internal/process/task_queues.js:94:5) {
  code: 205,
  name: 'XDebugError'
}
XDebugError: command is not available
    at new Response (/home/robin/.vscode/extensions/felixfbecker.php-debug-1.14.5/out/xdebugConnection.js:58:19)
    at Connection.<anonymous> (/home/robin/.vscode/extensions/felixfbecker.php-debug-1.14.5/out/xdebugConnection.js:613:20)
    at Generator.next (<anonymous>)
    at fulfilled (/home/robin/.vscode/extensions/felixfbecker.php-debug-1.14.5/out/xdebugConnection.js:5:58)
    at processTicksAndRejections (internal/process/task_queues.js:94:5) {
  code: 5,
  name: 'XDebugError'
}

@zobo i set the xdebug log level to 7 and attached the log file here, hope this helps somehow.
xdebug.log

My setup (inside the docker container):

• Apache 2.4.41
• php 7.4.13
• xdebug 3.0.1

Thanks for your effort and let me know if i can provide any additional information.

[zobo]

Great, thanks for he dump @R0Wi . I'll inspect it and get back to you with conclusions.

[R0Wi]

@zobo btw: i have to correct my statement from above: even if there are some errors in the console, all breakpoints seem to be hit correctly. But of course it would be interesting what causes the errors :-) Thanks for investigation 👍

[zobo]

Hello @R0Wi . I have researched the issue and came to the following conclusion; It's a design issue.

The issue happens when there are concurrent scripts being debugged. There is an already related PR #366, but I'll need to check this specific behavior anyway.

The debug adapter (this extension) gets calls from vscode (setBreakPointsRequest, setExceptionBreakPointsRequest, setFunctionBreakPointsRequest). This happens when the user changes any breakpoint or on the start of the debugging session. So if concurrent debug sessions exist (like in your log) VSCode will call those at the beginning of every session.

In each of those calls, for each connection a list of existing breakpoints is fetched from Xdebug, then the list is updated by removing current breakpoints and adding them again.

The limitation of Xdebug is that the DBGp connection is blocking, and nothing is processed on it, as long as the php process is executing code. Only after a break is hit, there can be any communication on it.

Because I see a <response ... command="run" transaction_id="6" status="break"... just before the issue, and a bunch of duplicate breakpoint_list and breakpoint_remove my conclusion is that at least two setBreakPointsRequest calls are running in parallel, because while one connection is in running state, at least two more got initiated and each of them caused a setBreakPointsRequest from VSCode.

The proper way to solve this is to delegate the breakpoint management code down from the adapter to the connection level.
And research how to properly handle multiple concurrent connections - be it "threads" or some other way.

@R0Wi next time I'll also ask for the VSCode debug log (enabled in launch.json).

I'll try to make a PR when time permits and have a look at it with @felixfbecker and @derickr - whenever they have time.

[R0Wi]

Great analysis, thanks @zobo. I think i also noticed the described "parallel behaviour" in the VSCode debuggers bottom left corner where the request threads of apache are shown. I noticed multiple entries while debugging and refreshing the Nextcloud webapplication. So this would fit to your suspicion of parallel things going on here.

If you need further information or log dumps just let me know, glad to help 👍

[L3P3]

So what does this mean guys? I want to debug a Magento 2 application and just use vs code for years now.
There seems to be a connection since in the debug view, it lists active requests appearing and disappearing. When I set a breakpoint thou, it says "command not supported" and "no such breakpoint".
Is the bottom line for me now just "nope, cannot do it"? Or what?
Thanks

[zobo]

Hi @L3P3.
I was looking for the right solution and came up with this #517.
It's taking a lot longer to implement as the changes are quite dramatic.

I'll try to provide a quick patch for the issue within the current plugin framework.

Once I have the other branch ready, would you be willing to test a prerelease?

Best!

[L3P3]

Actually, I noticed that setting breakpoints and all that works. I still get the error messages above but for most requests, it works, just about 5% fail.

[zobo]

This should be solved with the new breakpoint management subsystem. Let me know if there are more problems.