View Issue Details

Jump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0001735XdebugStep Debuggingpublic2020-01-17 12:282020-01-17 17:55
Reporterdnsnx Assigned To 
PrioritynormalSeverityblockReproducibilityalways
Status closedResolutionfixed 
Product Version2.9.0 
Target Version2.9.2Fixed in Version2.9.2 
Summary0001735: DBGp eval warning promoted to Exception can cause out-of-sync responses
Description

I'm having an issue with Visual Studio Code and Xdebug.

My System:
I'm using a Windows 10 system with IIS webserver and PHP version 7.4. I've downloaded and installed Xdebug with the last version (2.9.0) successfully (see the excerpt from the php.ini below). Visual Studio Code is configured for using Xdebug (see launch.json file below).

My issue is:
When I set a breakpoint, it stops at this breakpoint. So far so good. But if I press then "Step into" (F11) or "Step over" (F10) buttons, nothing is happening at all. The initial breakpoint is still highlighted - it stays at the breakpoint.

Maybe something is configured wrong, but actually I can't figure out what it is.

See here the configuration files:

php.ini:



[XDEBUG]

xdebug.remote_enable = 1

xdebug.remote_handler = dbgp

xdebug.remote_host = localhost

xdebug.remote_port = 9000

xdebug.remote_autostart = 1

xdebug.idekey=VSCODE

xdebug.remote_log ="C:\temp\xdebug.log"


[PHP_XDEBUG-2.9.0-7.4-VC15-NTS]

zend_extension = "C:\Program Files (x86)\PHP\v7.4\ext\php_xdebug-2.9.0-7.4-vc15-nts-x86_64.dll"

launch.json of Visual Studio Code:



{

// Verwendet IntelliSense zum Ermitteln möglicher Attribute.

// Zeigen Sie auf vorhandene Attribute, um die zugehörigen Beschreibungen anzuzeigen.

// Weitere Informationen finden Sie unter https://go.microsoft.com/fwlink/?linkid=830387

"version": "0.2.0",

"configurations": [

{

"name": "Listen for XDebug",

"type": "php",

"request": "launch",

"port": 9000,

"ignore": [

"/vendor//*.php"

]

},

{

"name": "Launch currently open script",

"type": "php",

"request": "launch",

"program": "${file}",

"cwd": "${fileDirname}",

"port": 9000

}

]

}

The solution was to clear all breakpoints (even on deleted files) and clear all variables in the "Watch"-section of Visual Studio Code.
See also issue on stackoverflow:

https://stackoverflow.com/questions/59748690/xdebug-visual-studio-code-step-into-step-over-nothing-happens

Steps To Reproduce

I can reproduce the error, when I enter variables in the "Watch"-section of Visual Studio Code.
It produces the attached log file.

TagsNo tags attached.
Operating SystemWindows 10
PHP Version7.4.0-7.4.4

Activities

derick

2020-01-17 12:35

administrator   ~0005217

Would you mind putting the log in an attached file?

dnsnx

2020-01-17 12:39

reporter   ~0005218

Log file attached...

derick

2020-01-17 16:21

administrator   ~0005219

Last edited: 2020-01-17 16:21

I see in the log:



[21784] <- eval -i 15 -- JHJlc3VsdEpzb24=

[21784] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="15" status="break" reason="ok"><xdebug:message filename="file://D:/Files/Company/Project/public/xdebug:/debug-eval" lineno="1" exception="ErrorException"><![CDATA[Undefined variable: resultJson]]></xdebug:message></response>

The normal undefined variable message seems to be converted to an ErrorException. Is this something that Laravel does? If so, can you show me a link to that implementation (probably something to do with set_error_handler ).

derick

2020-01-17 17:55

administrator   ~0005220

The PR for this has been merged (https://github.com/xdebug/xdebug/pull/543) and this fix will be part of Xdebug 2.9.2.

The story is:

This turned out to be a bug in Xdebug, which would happen when the following points are all true:

  • An error handler converted a warning/notice into an Exception
  • An exception breakpoint was set on this specific Exception, or a wild card exception breakpoint was set
  • The DBGp eval command, which IDEs often use to implement watches, created a warning or notice, in this case, due to an undefined variable.

The cause was that although the eval command turns of breakpoints with a breakpoints_allowed flag until it has been run, the breakpoint handler for exceptions did not check whether this breakpoints_allowed flag was actually set.

The fix is to check for the breakpoints_allowed flag in the handler for exception breakpoints.