Vscode-php-debug: Debug context lost on multiple connections

[ettoredn]

Relates to: #19 #167 #294 #231
PHP version: 7.2.7
XDebug version: 2.6.0
Adapter version: 1.12.5

Issue

When multiple connections are received, the debug context of the previous connection(s) cannot be retrieved from the editor.

For larger codebases (tested with WordPress) it seems that both debug contexts are lost resulting in an empty 'Call Stack', meaning the 'Call Stack' window is empty. The first connection is kept paused, whereas the second gets executed without pausing.

Steps to reproduce

Given the following PHP script debug-multi.php:

$a = ['bee', 'tiger', 'bear', 'deer'];
xdebug_break();
var_dump($a);

Step 1
Open a terminal and execute export XDEBUG_CONFIG="idekey=vscode"; php debug-multi.php.
The adapter correctly stops on the line following xdebug_break():

Step 2
Open a terminal and execute export XDEBUG_CONFIG="idekey=vscode"; php debug-multi.php.
The adapter correctly stops on the same line as step 1, but the previous request is shown as "Running" even if it is still paused (shell command has not returned):

Configuration settings

launch.json:

"name": "Listen for XDebug",
"type": "php",
"request": "launch",
   "port": 9000,
   "xdebugSettings": {
   "max_depth": 1,
    "max_children": 10
},
"log": true

php.ini:

xdebug.remote_enable = 1
xdebug.profiler_output_dir=/Users/ettore/Workspace/xdebug/profiling
xdebug.profiler_output_name=%u.%R
xdebug.profiler_enable_trigger=1
xdebug.remote_log = /Users/ettore/Workspace/xdebug/xdebug.log

Logs

First connection

1-adapter.log

Second connection

2-adapter.log

[Obyri]

I am getting this too, since the last week changes.
Any connection coming after the first break point (via ajax for example) is killing the first connection.
Leaving the debug in a hung state with no call stack or variable output in the debug windows.

The only way to fix is reset the debug session and try again.

I would fix myself but wouldn't know where to start.

[dceldran]

Hi,
I have the same problem, with the last version of visual studio code and the last version of the extension php debug, i lose the debug connection.

[nicolasbadia]

Same here. Previous version was working fine.

[natekinkead]

Having the same issue here on multiple machines. I only have a couple seconds to see the variables when it stops at a breakpoint before some ajax heartbeat in WordPress kills my debug session. Seems to be a bug introduced in v1.12.5.

[steyep]

I agree with the general consensus that the issue seems directly related to v1.12.5 and the solution implemented to prevent deadlocks. Unfortunately, the only thing that's worked for me is rolling back to v1.12.4 and disabling auto-updating extensions in VSCode.

[Obyri]

As per steyep, rollback is the way to go.
link to 1.12.4
uninstall and install VSIX.

[timothyallan]

'Install From VSIX' is a menu option in the "..." button dropdown in the extensions tab in VS Code for anyone else who didn't know how to install these .vsix files

[vothanhkiet]

I've also had the same problem, PHP 7.2.7, Xdebug 2.6.0, rollback the plugin to the previous version v1.12.4 work, need to turn off auto update as well.

[felixfbecker]

@jonyo since you implemented this in #294 and it seems to be a regression from that PR, could you look at investigating this? Otherwise I'm afraid I'll have to revert it :/

[jonyo]

@felixfbecker Yes I'll look into it today.

tl;dr: I'm going to work on a proper solution today but if I can't fix it by the end of the day, I'll at least put in a PR for a stop-gap fix to disable the part of the code causing it.

So I'm about 95% sure this is what is causing it:

https://github.com/felixfbecker/vscode-php-debug/blob/7fa2d28ef724d813bb76b5c034e623401fcea86d/src/phpDebug.ts#L282-L285

I think that is sometimes sending a continue signal when it is actually still paused. I have a free day today so I'll work on fixing that, if I'm not able to come up with a solution today then at the very least, I'll put in a PR to disable that part of the code so it does not send the signal at all. Since the problem it is fixing is not nearly as big of a deal as the new bug it caused.

For context, in case anyone is curious why it sends the continue signal in the above snippet: Without it, when you click continue or step or any of the options, the debugger does not realize that xdebug has indeed "continued" with executing PHP code, at least not until the next time it pauses or the script is done.

This results in the UI feeling like nothing happened, especially if clicking continue ends up running some PHP code that takes a while before it gets to the next breakpoint. The only hint that it did continue is that trying to interact with the context does not work, since the code has already moved on, and trying to eval code won't work for the same reason.

I think the "opposite" problem is happening now which is worse than the original problem that it fixes, now instead of looking like it is paused when it is not, it looks like the code continued when it did not. So like I said above I'll try to come up with a solution that will allow neither to happen, but if I do not make progress today I'll put that PR in place since the old problem is not as bad.

[jonyo]

@felixfbecker So I made 2 PR's for this because the actual solution ended up being a refactor that could likely take some time for discussion etc. So the first PR #307 just kills the part causing this error, and re-introduces the issue with the UI seeming to hang.

The second PR #308 re-fixes the ui-seems-to-hang problem the "right" way (see the description on the PR). Both of course I tried to test as thoroughly as possible.

[felixfbecker]

:tada: This issue has been resolved in version 1.12.6 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: