Breakpoints set offline never reached

[AnrDaemon]

PHP version: any
XDebug version: any
Adapter version: 1.12.6
VS Code: 1.29.1/Win64

Your launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for XDebug",
            "type": "php",
            "request": "launch",
            "port": 9000,
            "stopOnEntry": true,
            "pathMappings": {
                //"${workspaceRoot}": "${workspaceRoot}",
                //"${workspaceRoot}": ""
            }
        }
    ]
}

XDebug php.ini config: irrelevant

Code snippet to reproduce: any code

See attached image:

This is the same physical file.
The first (enabled) breakpoint was set when no debugger was connected. (Open from Explorer, scroll to line and hit F9.)
The second (disabled) breakpoint was set when a debugging session was inside the file in question.
Clicking on the breakpoints open TWO editing tabs.
I just can't wrap my mind around necessary pathMappings configuration. Already tried several positions with no success. Two "working" (as in, not breaking anything) variants are in the sample comments. But they do not change anything significantly.

The project is on local drive, VS Code opened at project root, all proper.

[AnrDaemon]

Please see bmewburn/vscode-intelephense#1865 and parent issue microsoft/vscode#112231

[zobo]

Hi! I'm not sure I'm getting all the information here. The issue is very old (2018) and in the mean time the path mapping code was improved to handle different drive letter cases and other edge cases.

One of the referenced issues mentions UNC paths. I'm guessing you are doing some sort of remote debugging (linux+samba). I had good experience with UNC mappings ( "pathMappings": { "${workspaceRoot}": "\\\\SERVER\\mount\\path" ... .
However the other referenced issue mentions WSL paths. There is an unresolved Xdebug problem that prevents you to work with breakpoints on such paths (https://bugs.xdebug.org/view.php?id=1964 the bug doesn't have all the talks we had with Derick).

I'm not sure how you got to the point where one file was opened twice (with different paths), but a mapping of "${workspaceRoot}": "" is definitely NOT OK.

I suggest you also try VSCode Remote SSH.

Let me know if this answers some of your questions and if not, we can define a problem more exactly so I can try to reproduce it.

[AnrDaemon]

Sorry, if I was needlessly abrupt.
Yes, some of the code was improved since then, but some issues remain.
UNC one is not necessarily a php-debug issue (though my observation indicating some connection), but this can still be worked around in the extension.
The issue can be observed in the case of workspace located on the UNC path.
When you open the workspace, initially everything looks fine; you configure path mapping et al, but once you start debugging, and xdebug tells extension to open the file, sometimes it open with host name lowercased.
This causes php-debug to treat it as located outside the workspace, or otherwise making it unable to map the path back to the debugged host.

[zobo]

Hi!
Would you be able to give me exact examples? Workspace path (UNC), mappings config, VSCode logs so I can try to make some tests to reproduce the issue? Thanks!

[AnrDaemon]

How to create the logs? That's probably the hardest part for me :)
The rest is easily reproducible (at least, in my env.)

[zobo]

Hi!
In your launch.json add log: true. In VSCode Panel the tab DEBUG CONSOLE will contain a comprehensive log after Xdebug connection happens. Do a right-click and Copy All and attach that here as a text file. Can you write here your UNC paths?

[AnrDaemon]

debug-console.log
launch.json.txt
php-xdebug.log

[zobo]

Hi. I do see some strange things I need to investigate. Here two breakpoints being set from VSCODE to DAP:

    source: {
      name: 'app.php',
      path: '\\\\HOSTING64.DARKDRAGON.LAN\\wwwroot\\ccenter\\app-core\\app.php'
    },
    lines: [ 11 ],

and

    source: {
      name: 'Url.php',
      path: '\\\\hosting64.darkdragon.lan\\wwwroot\\ccenter\\vendor\\anrdaemon\\library\\src\\Net\\Url.php'
    },
    lines: [ 323 ],

Being later transformed and sent to XDEBUG

xd(1) <- breakpoint_set -i 9 -t line -f file:///home/ccenter/app-core/app.php -n 11
xd(1) <- breakpoint_set -i 10 -t line -f file:///hosting64.darkdragon.lan/wwwroot/ccenter/vendor/anrdaemon/library/src/Net/Url.php -n 323

As seen here, the second one is not properly mapped.
Question is:

• why does VSCode see one file in upper case UNC host and second in lowercase UNC host?
• should the plugin try to map UNC case insensitive?

If I add case insensitivity here, what is going to happen when the breakpoint is triggered? And the plugin needs to map the path back to UNC? It will map it to uppercase UNC because that is what is in ${workspaceFolder} ...

Can you try to figure out when you get an uppercase UNC and when a lower case (when opening files and workspace in VSCode)?

[AnrDaemon]

why does VSCode see one file in upper case UNC host and second in lowercase UNC host?

Because it's a bug in VS Code. It doesn't do path normalization in all necessary cases.

should the plugin try to map UNC case insensitive?

Until the bug is fixed, it should uppercase host names of UNC paths on Windows.
You can trigger the bug yourself, if you install, say, https://marketplace.visualstudio.com/items?itemName=bmewburn.vscode-intelephense-client and open any class method through it.
An example reproduction path can be found in bmewburn/vscode-intelephense#1865 (comment)

[zobo]

I'm looking into it. Have managed to compile and run the intelephense extension and got a trace of LSP messages (this helped: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide). I need to setup a linux share to test it, but already tried it with WSL and there it seems that VSCode sees UNC with lowercase "host".

[Trace - 11:27:28] Sending request 'textDocument/definition - (3)'.
Params: {
    "textDocument": {
        "uri": "file://wsl%24/Ubuntu/home/zobo/php/test_is2.php"
    },
    "position": {
        "line": 2,
        "character": 24
    }
}


[Trace - 11:27:28] Received response 'textDocument/definition - (3)' in 1ms.
Result: [
    {
        "targetUri": "file://wsl%24/Ubuntu/home/zobo/php/test_is.php",
        "targetRange": {
            "start": {
                "line": 2,
                "character": 0
            },
            "end": {
                "line": 5,
                "character": 1
            }
        },
        "targetSelectionRange": {
            "start": {
                "line": 2,
                "character": 6
            },
            "end": {
                "line": 2,
                "character": 11
            }
        },
        "originSelectionRange": {
            "start": {
                "line": 2,
                "character": 20
            },
            "end": {
                "line": 2,
                "character": 25
            }
        }
    }
]

PHP on the other hand, does strange things:

Fatal error: Uncaught Error: Class "Test1" not found in \\WSL$\UBUNTU\home\zobo\php\test_is2.php:3
Stack trace:
#0 {main}
  thrown in \\WSL$\UBUNTU\home\zobo\php\test_is2.php on line 3

And because of that, also Xdebug:

<?xml version="1.0" encoding="iso-8859-1"?><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://WSL%24/UBUNTU/home/zobo/php/test_is2.php" lineno="3" exception="Fatal error" code="1"><![CDATA[Uncaught Error: Class "Test1" not found in \\WSL$\UBUNTU\home\zobo\php\test_is2.php:3Stack trace:#0 {main}  thrown]]></xdebug:message></response>

I've already opened a bug with Xdebug, but this is a larger issue than just Xdebug. Its a PHP issue. https://bugs.xdebug.org/view.php?id=1964

I could also get VSCode to open different versions of the folder by running from command line:

code \\WSL$\ubuntu\home\zobo\php
code \\wsl$\Ubuntu\home\zobo\php
code \\WSL$\UBUNTU\home\zobo\php

I did almost get things working by opening the folder with code \\WSL$\UBUNTU\home\zobo\php and then added mapping

            "pathMappings": {
                "$/UBUNTU/home/zobo/php": "${workspaceRoot}"
            }

However, setting breakpoints is still broken because the reverse computation just can't figure it out:
breakpoint_set -i 4 -t line -f file:///$/UBUNTU/home/zobo/php/test_is.php -n 9

My suggestion right now, try to assign a drive letter to he UNC path and open the folder with something like X:\php\src....

I'll try to come back around this strange case, and at least figure out where the core of the problem lies...

[AnrDaemon]

WSL paths are a bigger headache than regular UNC paths.
BTW, you don't need a linux host to test, you can loop back to yourself on the Windows host.

Probably (PROBABLY!) an easy achievements would be to compare host and first path component of the breakpoint caselessly on Windows. So, say, \\\\HOST\\Path\\… and \\\\host\\path\\… would map the same?

Assigning drive letters is a big security hole I learned to avoid in my younger years.
Not once my clients had lost their information because a trojan scrambled their filesystem enumerating [A-Z]:, and not once they were saved because users learned to work through UNC paths directly.