Xdebug connects tothe Dbgp plugin but doesn't work

Scrolin

I’ve recently installed Xdebug and the Npp Dbgp plugin following the instructions. Calling xdebug_break or xdebug_info in the PHP CLI, the connection is established with the Npp IDE which immediately throws up a a message

Unable to map remote: file//C:/PHP php shell code (ip: 127.0.0.1 idekey:  local_setup) fallbeck to source

The PHP CLI waits until the message is acknowledged, when it comes back with a command entry prompt (following the xdebug_info output), and the Npp IDE throws up an error message

Element "Error" does not contain a single text node.

The same happens when xdebug_break is called from within a function in a script ( even the file name in the first message is unchanged), and script execution continues. All, breakpoints and watches are ignored.

Setting/unsetting the ‘Use SOURCE command…’ and/or the ‘Break at first line…’ options in the Dbgp config don’t have any affect.

Is this a bug, or am I doing something wrong?

Here is the Npp debug info

Notepad++ v8.5.8   (64-bit)
Build time : Oct 15 2023 - 21:43:56
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 10 Home (64-bit)
OS Version : 22H2
OS Build : 19045.3693
Current ANSI codepage : 1252
Plugins : 
    dbgpPlugin (0.14.1)
    mimeTools (2.9)
    NppConverter (4.5)
    NppExport (0.4)
    NPPJSONViewer (1.40)
    XMLTools (3.1.1.13)

and here is the xdebug_info output

__   __   _      _
\ \ / /  | |    | |
 \ V / __| | ___| |__  _   _  __ _
  > < / _` |/ _ \ '_ \| | | |/ _` |
 / . \ (_| |  __/ |_) | |_| | (_| |
/_/ \_\__,_|\___|_.__/ \__,_|\__, |
                              __/ |
                             |___/

Version => 3.1.6
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support

             Enabled Features (through 'xdebug.mode' setting)
Feature => Enabled/Disabled
Development Helpers => ✘ disabled
Coverage => ✘ disabled
GC Stats => ✘ disabled
Profiler => ✘ disabled
Step Debugger => ✔ enabled
Tracing => ✘ disabled

                            Optional Features
Compressed File Support => yes (gzip)
Clock Source => GetSystemTimePreciseAsFileTime

                              Diagnostic Log
No messages

                              Step Debugging
Debugger is active
Connected Client => localhost:9003

DBGp Settings
Max Children => 15
Max Data => 512
Max Depth => 3
Show Hidden Properties => No
Extended Properties => No
Notifications => No
Resolved Breakpoints => No
Breakpoint Details => No

                                   PHP
                           Build Configuration
Version (Run Time) => 7.4.30
Version (Compile Time) => 7.4.33
Debug Build => no
Thread Safety => disabled
                                 Settings
Configuration File (php.ini) Path =>
Loaded Configuration File => C:\PHP\php.ini
Scan this dir for additional .ini files => (none)
Additional .ini files parsed => (none)

Directive => Local Value => Master Value
xdebug.mode => debug => debug
xdebug.start_with_request => yes => yes
xdebug.start_upon_error => default => default
xdebug.output_dir => C:\Windows\Temp => C:\Windows\Temp
xdebug.use_compression => 1 => 1
xdebug.trigger_value => no value => no value
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.log => C:\PHP\xdebug.log => C:\PHP\xdebug.log
xdebug.log_level => 7 => 7
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3
xdebug.max_nesting_level => 256 => 256
xdebug.cli_color => 0 => 0
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.halt_level => 0 => 0
xdebug.max_stack_frames => -1 => -1
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.profiler_append => Off => Off
xdebug.cloud_id => no value => no value
xdebug.client_host => localhost => localhost
xdebug.client_port => 9003 => 9003
xdebug.discover_client_host => Off => Off
xdebug.client_discovery_header => no value => no value
xdebug.idekey => no value => no value
xdebug.connect_timeout_ms => 200 => 200
xdebug.scream => Off => Off
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_return => Off => Off

And finally here is the xdebug log (as you can see there have been many attempts)

[17192] Log opened at 2023-11-20 15:28:27.069873
[17192] [Step Debug] INFO: Connecting to configured address/port: localhost:9003.
[17192] [Step Debug] INFO: Connected to debugging client: localhost:9003 (through xdebug.client_host/xdebug.client_port). :-)
[17192] [Step Debug] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file://C:/PHP/php shell code" language="PHP" xdebug:language_version="7.4.30" protocol_version="1.0" appid="17192"><engine version="3.1.6"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2022 by Derick Rethans]]></copyright></init>

[17192] [Step Debug] <- source -i 1 -f file://C:/PHP/php shell code
[17192] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="source" transaction_id="1"><error code="1"><message><![CDATA[parse error in command]]></message></error></response>

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

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

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

[17192] [Step Debug] <- breakpoint_set -i 5 -t line -f file:///%2F%2Fnsrcscoring%2FPHP_Scripts%2FNSRC+Squadding+New.php -n 1583 -s enabled -h 0 -o >=
[17192] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="5" state="enabled" id="171920001"></response>

[17192] [Step Debug] <- breakpoint_list -i 6
[17192] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_list" transaction_id="6"><breakpoint type="line" filename="file:///nsrcscoring/PHP_Scripts/NSRC%2BSquadding%2BNew.php" lineno="1583" state="enabled" hit_count="0" hit_condition="&gt;=" hit_value="0" id="171920001"></breakpoint></response>

[17192] [Step Debug] <- step_into -i 7

Michael Vincent

@Scrolin said in Xdebug connects tothe Dbgp plugin but doesn't work:

Xdebug and the Npp Dbgp plugin

@rdipardo ported the DBGp plugin to 64-bit but I don’t think is adding features. He may be able to answer your question so @ referencing him here to grab his attention.

Cheers.

rdipardo

@Scrolin,

From your information I think the issue is how Xdebug or the plugin is configured (or both). It works for me, but I’ve only ever used it on very trivial scripts:

dbgp-0.14.1-npp-8.6RC1.png

In my PHP’s conf.d folder, I have this (and only this) in xdebug.ini:

[xdebug]
xdebug.mode=debug
error_reporting=E_ALL
force_display_errors=1

All of DBGp’s options are in the default state. In fact there is currently no dbgp.ini in $(NPP_DIR)\plugins\Config. Try removing any INI file you may have in your config path first.

Also keep in mind that the plugin can only communicate with Xdebug in a single-byte encoding (such as ISO-8859-1, as the Raw DBGp dialog is showing in the screen capture above). Click the DBG button on the plugin’s debugger panel while the server is connected and make sure the output is readable. If it looks like nonsensical Chinese, then Xdebug is most likely sending requests in UTF-8. That should not be the case in the default operating mode, so I suggest clearing out any custom configurations.

Setting/unsetting the ‘Use SOURCE command…’ and/or the ‘Break at first line…’ options in the Dbgp config don’t have any affect.

Is this a bug, or am I doing something wrong?

To be honest I haven’t spent much time exploring which options are actually functional. Damjan Cvetko originally developed DGBp for ANSI Notepad++. Released versions from that era can’t even load the configuration if the file path contains international characters. I think I’ve made it sufficiently Unicode-aware for basic functionality, but as mentioned it still can’t decipher requests in a multi-byte encoding.

Like @Michael-Vincent mentioned, there’s no roadmap for any major enhancement soon, if ever. I’m only maintaining DBGp in the interest of preserving a classic piece of software. PHP devs have plenty of better options nowadays.

rdipardo

@Scrolin said in Xdebug connects tothe Dbgp plugin but doesn't work:

[17192] [Step Debug] <- source -i 1 -f file://C:/PHP/php shell code
[17192] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="source" transaction_id="1"><error  code="1"><message><![CDATA[parse error in command]]></message></error></response>

O.K., I get an error response if I just enable [ ] SOURCE command for all files and bypass maps in the config menu:

dbgp-0.14.1-npp-8.6rc1-source-cmd.png

Note that in my setup there’s no Xdebug server up and running; I just have PHP configured to load php_xdebug.dll whenever I invoke the preprocessor.

No problems when [ ] Break at first line . . . is enabled. Just disable the “SOURCE command …” option and see what happens.

Scrolin

Thanks @rdipardo, I guess I’ll just have to get to grips with VS Code. A shame as I like NPP’s simplicity

rdipardo

I will wait for feedback on the latest version before updating the distributed plugin list: https://bitbucket.org/rdipardo/dbgp/src/v0.14.2/CHANGELOG.txt

This thread has already climbed the search engine rankings for Xdebug issues, so I didn’t want to leave the impression that DBGp is unmaintained.

Lesson learned: Delphi Strings are implicitly passed by reference (as if the type identifier were PChar instead). That means this method would overwrite a validly escaped file URI with the file’s literal path — spaces, backslashes, and all — which the debugger obviously can’t find. Still no luck getting UNC paths to resolve to proper URIs, but that seems to be a known issue with Xdebug itself.

Simply getting the source command to execute was only the beginning of the trouble. The message parsing code was written for an obsolete spec, when error nodes were simple text elements. Treating them as such was raising DOM exceptions that obscured real debugger errors, and calling methods on a missing node object would cause the occasional access violation. Then I found out the socket destructor would be invoked twice; once when the temporary source map was unloaded, once more when the socket closed, and the second time around it tried to look up the same unloaded file, calling a method on a member object it had already freed.

All of this came to light only after source mapping started to work, but only for local files in ideal conditions, which makes me wonder about the stability of future releases. The feature set of current versions is definitely crippled, but that also means they can’t fail too dangerously. Like the classic car it really is, DBGp is not for daily driving.