Local to server path translation fails

[sevaa]

PHP version: 5.6.17-0+deb8u1
XDebug version: 2.2.5
Adapter version: 1.11.1

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,
            "localSourceRoot": "R:\\yarxidev",
            "serverSourceRoot": "/home/seva/yarxidev",
            "stopOnEntry":false
        }
    ]
}

XDebug php.ini config:

zend_extension=xdebug.so

xdebug.remote_enable=true
xdebug.remote_host=mybox
xdebug.remote_port=9000
xdebug.remote_log=/tmp/xdebug/xdebug-remote.log
xdebug.remote_autostart=1

xdebug.remote_handler=dbgp
xdebug.profiler_enable=0
xdebug.profiler_output_dir=/tmp/xdebug

XDebug logfile (from setting xdebug.remote_log in php.ini):
xdebug-remote.log

---

My project resides on a folder on a Debian Linux server with XDebug, and I'm trying to debug it from a Windows machine. The server-side path of the project is /home/seva/yarxidev. It's shared via SAMBA as \servername\yarxidev. It's mapped to the Y: drive on my Windows box.

When I try to debug, the breakpoints are not hit unless stopOnEntry is set to true. If I look at the Xdebug log, the path to the file that it gets is file:///home/seva/y:/admin_main.php, which is wrong.

Opening the folder via its UNC path doesn't help; in an unrelated bug, VSCode doesn't see launch.json at all, there are no launch configurations present in the list.

Mapping /home/seva as R: and opening R:\yarxidev in VSCode doesn't help, either.

[felixfbecker]

So from the logs I see

<- breakpoint_set -i 9 -t line -f file:///S:%5Cartjoo%5Cindex.php -n 49

which is obviously wrong.
In your description you said you mapped it to Y:. Your launch.json uses R:. The logs use S:. What is the real value?

[sevaa]

I have all three disks mapped to folders on that server - S, R, and Y :) The clean case of the issue is on Y:, which corresponds to /home/seva/yarxidev. That one is in the log, too. Near the bottom.

[felixfbecker]

Could you give me your debug adapter log (as mentioned in the issue template)?

[felixfbecker]

Even better would be a failing test case. Here's the test that should cover your case:

https://github.com/felixfbecker/vscode-php-debug/blob/ed5a99d0d4a5e6840186c21890b7027901609b2e/src/test/paths.ts#L42-L49

[sevaa]

Where can I find the debug adapter log, please?

[felixfbecker]

In the debug console after setting log to true in launch.json

[sevaa]

Started debugging, brought up the admin_main page. Got this:

<- launchResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 2,
  command: 'launch',
  success: true }
new connection 1
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'started', threadId: 1 } }
<- initializedEvent
InitializedEvent { seq: 0, type: 'event', event: 'initialized' }
-> threadsRequest
{ command: 'threads', type: 'request', seq: 3 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 3,
  command: 'threads',
  success: true,
  body: { threads: [ Thread { id: 1, name: 'Request 1 (6:45:45 PM)' } ] } }
-> setBreakpointsRequest
{ command: 'setBreakpoints',
  arguments: 
   { source: { path: 'y:\\db.php', name: 'db.php' },
     lines: [ 770 ],
     breakpoints: [ { line: 770 } ],
     sourceModified: false },
  type: 'request',
  seq: 4 }
-> setBreakpointsRequest
{ command: 'setBreakpoints',
  arguments: 
   { source: { path: 'y:\\admin_main.php', name: 'admin_main.php' },
     lines: [ 5 ],
     breakpoints: [ { line: 5 } ],
     sourceModified: false },
  type: 'request',
  seq: 5 }
<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 4,
  command: 'setBreakpoints',
  success: true,
  body: { breakpoints: [ { verified: true, line: 770 } ] } }
<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 5,
  command: 'setBreakpoints',
  success: true,
  body: { breakpoints: [ { verified: true, line: 5 } ] } }
-> setFunctionBreakpointsRequest
{ command: 'setFunctionBreakpoints',
  arguments: { breakpoints: [] },
  type: 'request',
  seq: 6 }
<- setFunctionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 6,
  command: 'setFunctionBreakpoints',
  success: true,
  body: { breakpoints: [] } }
-> setExceptionBreakpointsRequest
{ command: 'setExceptionBreakpoints',
  arguments: { filters: [ '*' ] },
  type: 'request',
  seq: 7 }
<- setExceptionBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 7,
  command: 'setExceptionBreakpoints',
  success: true }
-> configurationDoneRequest
{ command: 'configurationDone', type: 'request', seq: 8 }
-> threadsRequest
{ command: 'threads', type: 'request', seq: 9 }
<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 9,
  command: 'threads',
  success: true,
  body: { threads: [ Thread { id: 1, name: 'Request 1 (6:45:45 PM)' } ] } }
<- configurationDoneResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 8,
  command: 'configurationDone',
  success: true }
<- threadEvent
ThreadEvent {
  seq: 0,
  type: 'event',
  event: 'thread',
  body: { reason: 'exited', threadId: 1 } }

[felixfbecker]

That log mentions y:\admin_main.php, but that doesn't match the localSourceRoot setting in your launch.json. Could you please give me a real local file name, local and server source root and the server file name?

[sevaa]

Shoot. Obsolete launch.json, sorry. Now it looks like this:

{
    // 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,
            "localSourceRoot": "Y:\\",
            "serverSourceRoot": "/home/seva/yarxidev",
            "stopOnEntry":false,
            "log": true
        }
    ]
}

I'm trying to find a workaround on my end, too.

[felixfbecker]

To be clear, the right server path would be /home/seva/yarxidev/admin_main.php?

[sevaa]

Yes, /home/seva/yarxidev/admin_main.php . Both Y:\ and R:\yarxidev point at that folder.

[felixfbecker]

The casing doesn't match. VS Code sends y:\admin_main.php, but you stated Y:\ as you local root.

[sevaa]

Windows drive letters are case insensitive.

[sevaa]

Changing the localSourceRoot to y:\ helps. Thank you!

[sevaa]

I saw your commit. I'm afraid it will break for scenario such as mine, if the server path is a Linux one and it contains uppercase letters. Given server path setting like /home/Seva/Foo, it will return a URL like file://home/seva/foo.

And I can't imagine what happens if the client machine is Linux, too. I've never used VSCode on Linux, only read about it.

[felixfbecker]

Not sure why you think that'd break. This only lowercases the drive letter

[sevaa]

Oops, sorry, it seemed to me on the first glance that it would lowercase the whole path.

[ZurabWeb]

@sevaa @felixfbecker So seems like this is not an issue?

[sevaa]

Not anymore, there's an obvious workaround. It's still a bug, drive letters should not be treated as case insensitive.

[ZurabWeb]

@sevaa Please go ahead and close the issue on github.

As a side note, not all operating systems treat drive letters as case insensitive, it's up to the developer of the OS usually, in your case Microsoft (?).

[sevaa]

Other than Windows (and ancient MS-DOS, and also CP/M), name one OS with a concept of drive letters :)

[ZurabWeb]

@sevaa I remember Symbian used to have it, as well as Xbox I think. Unix based systems don't have the drive letters usually, but other non-unix ones sometimes do.

P.S. This is getting off-topic.

[zobo]

Already solved #245. And the wonderful discussion about drive letters should be had somewhere they serve 🍻 😁