vscode-php-debug Watch broken

If debugger is active, value in watch is present beforehand and it can be resolved, an empty response is sent (xdebug crashes?)

Example of what is broken:

add strlen('test') to watch panel
make a request
observe empty response in browser/cURL

Example of what still works:

add xdebug_break(); in code
make a request
when paused on breakpoint add strlen('test') to watch panel
observe value being displayed
press "Continue" in debugger panel
response is sent as it should

Example of what does not cause an issue:

add made_up_function('test') to watch panel
make a request
observe request being sent normally

Apr 23 '25 10:04 HMartusewiczVox

Can confirm it works fine in version 1.35

Apr 23 '25 10:04 HMartusewiczVox

What is the Xdebug version?

Apr 23 '25 13:04 zobo

Also, please provide a Xdebug log. strlen('test') should evaluate like before, so in this case there should not be any changes. Also if the debugger does not stop (no breakpoint or xdebug_break() the watch will not evaluate.

Apr 23 '25 13:04 zobo

I mean, it broke with extension 1.36. Xdebug in my docker container is:

root@48fb43baa310:/var/www/html# php -r "var_dump(phpversion('xdebug'));"
Command line code:1:
string(5) "3.4.2"

Apr 23 '25 14:04 HMartusewiczVox

Also if the debugger does not stop (no breakpoint or xdebug_break() the watch will not evaluate

Ok, I think that was caused by some breakpoint being "lost" (not displayed, but still there) due to me editing the code on which it was placed

Apr 23 '25 14:04 HMartusewiczVox

This is what I got in log using extension v1.36

[653] Log opened at 2025-04-23 14:35:03.646631
[653] [Config] WARN: Not setting up control socket with default value due to unavailable 'tsc' clock
[653] [Step Debug] INFO: Connecting to configured address/port: host.docker.internal:9000.
[653] [Step Debug] INFO: Connected to debugging client: host.docker.internal:9000 (through xdebug.client_host/xdebug.client_port).
[653] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/html/public_html/index.php" language="PHP" xdebug:language_version="8.1.31" protocol_version="1.0" appid="653"><engine version="3.4.2"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2025 by Derick Rethans]]></copyright></init>

[653] [Step Debug] <- feature_set -i 1 -n resolved_breakpoints -v 1
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="1" feature="resolved_breakpoints" success="1"></response>

[653] [Step Debug] <- feature_set -i 2 -n notify_ok -v 1
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="2" feature="notify_ok" success="1"></response>

[653] [Step Debug] <- feature_set -i 3 -n extended_properties -v 1
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="3" feature="extended_properties" success="1"></response>

[653] [Step Debug] <- feature_set -i 4 -n breakpoint_include_return_value -v 1
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="4" feature="breakpoint_include_return_value" success="1"></response>

[653] [Step Debug] <- feature_set -i 5 -n max_data -v -1
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="5" feature="max_data" success="1"></response>

[653] [Step Debug] <- feature_set -i 6 -n max_depth -v 4
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="6" feature="max_depth" success="1"></response>

[653] [Step Debug] <- feature_set -i 7 -n max_children -v 100
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="7" feature="max_children" success="1"></response>

[653] [Step Debug] <- run -i 8
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="8" status="break" reason="ok"><xdebug:message filename="file:///var/www/html/application/..." lineno="71"></xdebug:message></response>

[653] [Step Debug] <- stack_get -i 9
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="9">I've removed the stack trace, it looked OK</response>

[653] [Step Debug] <- eval -i 10 -- JEdMT0JBTFNbJ2V2YWxfY2FjaGUnXVsnZjlmYTVlMTMtMTEyMy00ZjdmLWJhYTUtNzdhZGNlNzIzODVkJ109c3RybGVuKCd0ZXN0Jyk=
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="10"><property type="int"><![CDATA[4]]></property></response>

[653] [Step Debug] <- context_names -i 11 -d 0
[653] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="context_names" transaction_id="11"><context name="Locals" id="0"></context><context name="Superglobals" id="1"></context><context name="User defined constants" id="2"></context></response>

[653] [Step Debug] <- property_get -i 12 -d 0 -c 1 -n "$eval_cache['f9fa5e13-1123-4f7f-baa5-77adce72385d']"

And in docker logs

2025-04-23 16:35:04 [Wed Apr 23 16:35:04.564392 2025] [core:notice] [pid 634:tid 634] AH00052: child pid 653 exit signal Segmentation fault (11)

Apr 23 '25 14:04 HMartusewiczVox

Also if the debugger does not stop (no breakpoint or xdebug_break() the watch will not evaluate

Ok, I think that was caused by some breakpoint being "lost" (not displayed, but still there) due to me editing the code on which it was placed

I do not found a way to reproduce that, it has happened a few times before and I suspect this is a VSCode bug. I think we can ignore that, just the cache is broken

Apr 23 '25 14:04 HMartusewiczVox

Thanks, I currently use 3.5.0-dev...

xd(1) <- eval -i 13 -- JEdMT0JBTFNbJ2V2YWxfY2FjaGUnXVsnNzFjNDQ2ZDQtYWNmMC00MTM0LTg4YzUtZWM0ZmI5OWNlOTY1J109c3RybGVuKCd0ZXN0Jyk=
xd(1) -> <?xml version="1.0" encoding="iso-8859-1"?><response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="13"><property type="int"><![CDATA[4]]></property></response>
...
xd(1) <- property_get -i 16 -d 0 -c 1 -n "$eval_cache['71c446d4-acf0-4134-88c5-ec4fb99ce965']"
xd(1) -> <?xml version="1.0" encoding="iso-8859-1"?><response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="property_get" transaction_id="16"><property name="$eval_cache[&#39;71c446d4-acf0-4134-88c5-ec4fb99ce965&#39;]" fullname="$eval_cache[&#39;71c446d4-acf0-4134-88c5-ec4fb99ce965&#39;]" type="int"><![CDATA[4]]></property></response>

Could be a Xdebug issue, I need to test.

Apr 23 '25 15:04 zobo

I've tested this locally on a Linux VM by setting up a dev container based on

{
	"image": "php:8.1.31-apache-bookworm"
}

Xdebug version 3.4.2, PHP 8.1.31 NTS

echo implode(", ", get_loaded_extensions());
Core, date, libxml, openssl, pcre, sqlite3, zlib, ctype, curl, dom, fileinfo, filter, ftp, hash, iconv, json, mbstring, SPL, session, PDO, pdo_sqlite, standard, posix, Reflection, Phar, SimpleXML, tokenizer, xml, xmlreader, xmlwriter, mysqlnd, apache2handler, sodium, xdebug

No crash, works as expected.

Do you perhaps have some PHP extension that could cause this?

What happens if you remove the watch and then type strlen('test') into the debug console REPL?

Apr 24 '25 05:04 zobo

We've tested across coworkers and it appears to be broken on Apple Silicon Macs. Our docker image is build based on top of an ARM image. In dockerfile it's FROM php:8.1.31-apache. I'm not entirely sure, but I may have this exact one: https://hub.docker.com/layers/library/php/8.1.31-apache-bookworm/images/sha256-f30f963da9c712edd1b4955b66af555e4a96d7f4828b317c1a42dcbe4d3af302

Extensions

Core, date, libxml, openssl, pcre, sqlite3, zlib, ctype, curl, dom, fileinfo, filter, ftp, hash, iconv, json, mbstring, SPL, session, PDO, pdo_sqlite, bz2, posix, Reflection, standard, SimpleXML, tokenizer, xml, xmlreader, xmlwriter, mysqlnd, apache2handler, bcmath, Phar, calendar, exif, gd, gettext, gmp, imagick, imap, intl, memcached, mysqli, pcntl, pdo_mysql, soap, sockets, sodium, zip, xdebug

What happens if you remove the watch and then type strlen('test') into the debug console REPL?

It works fine:

As far as I can see, problem is only with watch and only when successfully evaluating values entered in previous sessions.

This is the output of php -i

Apr 24 '25 10:04 HMartusewiczVox

Thanks for all this, I'll look into it more. But it's strange that watch would not work, where REPL would. Both cases should produce the exact same interaction with Xdebug. Can I ask you for a Xdebug log?

I have access to a Mac Mini M1, I can try to install docker there and repeat the process.

Apr 24 '25 11:04 zobo

I've installed Docker and ran again the same test with devcontainer. Again no crash. Docker image is 8.1.31-apache-bookwork 7efcdf61001f. The only thing I modified was to install Xdebug with pecl install xdebug and created /usr/local/etc/php/conf.g/xdebug.ini with

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20210902/xdebug.so
xdebug.mode=debug
xdebug.start_with_request=yes

-> evaluateRequest
{ command: 'evaluate',
  arguments: { expression: "strlen('test')", frameId: 1, context: 'watch' },
  type: 'request',
  seq: 12 }
xd(1) <- eval -i 11 -- JEdMT0JBTFNbJ2V2YWxfY2FjaGUnXVsnOWRlNGI3NTYtMmIwNy00YTNlLWI2MDctNzY2ZjNjZTkwOTA4J109c3RybGVuKCd0ZXN0Jyk=
xd(1) -> <?xml version="1.0" encoding="iso-8859-1"?><response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="11"><property type="int"><![CDATA[4]]></property></response>
xd(1) <- context_names -i 12 -d 0
xd(1) -> <?xml version="1.0" encoding="iso-8859-1"?><response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="context_names" transaction_id="12"><context name="Locals" id="0"></context><context name="Superglobals" id="1"></context><context name="User defined constants" id="2"></context></response>
xd(1) <- property_get -i 13 -d 0 -c 1 -n "$eval_cache['9de4b756-2b07-4a3e-b607-766f3ce90908']"
xd(1) -> <?xml version="1.0" encoding="iso-8859-1"?><response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="property_get" transaction_id="13"><property name="$eval_cache[&#39;9de4b756-2b07-4a3e-b607-766f3ce90908&#39;]" fullname="$eval_cache[&#39;9de4b756-2b07-4a3e-b607-766f3ce90908&#39;]" type="int"><![CDATA[4]]></property></response>
<- evaluateResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 12,
  command: 'evaluate',
  success: true,
  body: { result: '4', variablesReference: 0 } }

To debug this I'd probably need a core dump from apache/php/xdebug. But since it cannot be isolated easily this is quite problematic...

Please check the logs if both watch and REPL produce the same Xdebug DBGp commands in the log.

full log

``` new connection 1 from ::1 xd(1) -> xd(1) xd(1) xd(1) xd(1) xd(1) xd(1) -> xd(1) threadsRequest { command: 'threads', type: 'request', seq: 8 } stackTraceRequest { command: 'stackTrace', arguments: { threadId: 1, startFrame: 0, levels: 20 }, type: 'request', seq: 9 } xd(1) threadsRequest { command: 'threads', type: 'request', seq: 10 } stackTraceRequest { command: 'stackTrace', arguments: { threadId: 1, startFrame: 0, levels: 20 }, type: 'request', seq: 11 } xd(1) evaluateRequest { command: 'evaluate', arguments: { expression: "strlen('test')", frameId: 1, context: 'watch' }, type: 'request', seq: 12 } xd(1) xd(1) xd(1) scopesRequest { command: 'scopes', arguments: { frameId: 1 }, type: 'request', seq: 13 } xd(1) variablesRequest { command: 'variables', arguments: { variablesReference: 1 }, type: 'request', seq: 14 } xd(1) evaluateRequest { command: 'evaluate', arguments: { expression: "strlen('test')", frameId: 1, context: 'repl' }, type: 'request', seq: 15 } xd(1) xd(1) xd(1) scopesRequest { command: 'scopes', arguments: { frameId: 1 }, type: 'request', seq: 16 } xd(1) evaluateRequest { command: 'evaluate', arguments: { expression: "strlen('test')", frameId: 1, context: 'watch' }, type: 'request', seq: 17 } xd(1) -> xd(1) xd(1) xd(1) variablesRequest { command: 'variables', arguments: { variablesReference: 4 }, type: 'request', seq: 18 } xd(1) continueRequest { command: 'continue', arguments: { threadId: 1 }, type: 'request', seq: 19 } xd(1)

Apr 24 '25 12:04 zobo

I don't really know what to look for, but you've actually helped to fix it for me. I've had in my .ini:

xdebug.mode=debug,develop,profile

and after noticing you tested with just debug I've tried that and there were no issues. After adding develop the crashes are back. No issues with profile.

I'm fine with not having that enabled, so we can call it "solved" for me.

Can you try it with develop and see if that allows you to reproduce?

Apr 28 '25 13:04 HMartusewiczVox

Tested on coworkers: macbook, removing develop also fixed the issue.

Apr 28 '25 13:04 HMartusewiczVox

Thanks! I'll test it as soon as possible.

Apr 28 '25 19:04 zobo

Hey. Tried it both on Linux and MacOS, cannot reproduce. So it has to be something else, or specific to hardware that I do not have.

Apr 29 '25 05:04 zobo

Tried to install all listed modules and still could not reproduce. Could you share your Dockerfile?

May 03 '25 06:05 zobo

Please reopen if needed.

Aug 06 '25 21:08 zobo