• Login
Community
  • Login

Xdebug connects tothe Dbgp plugin but doesn't work

Scheduled Pinned Locked Moved Help wanted · · · – – – · · ·
6 Posts 3 Posters 621 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • S
    Scrolin
    last edited by Nov 20, 2023, 5:01 PM

    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
    
    M R 3 Replies Last reply Nov 20, 2023, 5:05 PM Reply Quote 1
    • M
      Michael Vincent @Scrolin
      last edited by Michael Vincent Nov 20, 2023, 5:06 PM Nov 20, 2023, 5:05 PM

      @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.

      1 Reply Last reply Reply Quote 3
      • R
        rdipardo @Scrolin
        last edited by rdipardo Nov 21, 2023, 1:43 PM Nov 21, 2023, 11:16 AM

        @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.

        1 Reply Last reply Reply Quote 3
        • R
          rdipardo @Scrolin
          last edited by Nov 21, 2023, 1:42 PM

          @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.

          1 Reply Last reply Reply Quote 3
          • S
            Scrolin
            last edited by Nov 24, 2023, 10:33 AM

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

            1 Reply Last reply Reply Quote 0
            • R
              rdipardo
              last edited by Nov 26, 2023, 4:18 PM

              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.

              1 Reply Last reply Reply Quote 4
              3 out of 6
              • First post
                3/6
                Last post
              The Community of users of the Notepad++ text editor.
              Powered by NodeBB | Contributors