Remote debugging failed with warning "pydev debugger: warning: try to add breakpoint to file that does not exist"

[DonJayamanne]

@xiaofeng0123 commented on Tue Apr 02 2019

Visual Studio Code - Insiders: 1.33.0-insider
python-insider: 2019.4.6365-alpha
ptvsd version: 4.2.6

Repro step:

1. Create a python file named remote_debug.py with below code:
   import ptvsd
   ptvsd.enable_attach(('IP of unbuntu',5678))
   ptvsd.wait_for_attach()
   for i in range(1,10,2):
   print(i)
   print('demo done')
2. Copy this file to ubuntu which should include ptvsd installed with same version as current machine
3. Execute python file in ubuntu:
   python3 remote_debug.py
4. In VSC, set DEBUG to "Python:Remote Attach", and set the path mappings and host value
   
5. Set breakpoint on current machine and press F5 to start debugging

Actual Result:
Fail to hit breakpoint with warning "pydev debugger: warning: trying to add breakpoint to file that does not exist..."

Expect Result:
It should hit breakpoint

[karthiknadig]

@xiaofeng0123 From the paths it looks like the remote root might not be correct.
Can you try with following path mapping?

            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}",
                    "remoteRoot": "."
                }
            ],

If that does not work, can you provide more details about your project layout local and remote.

[DonJayamanne]

@karthiknadig Could be a dup of #1297
Problems with Path mappings

[erasmusa]

I have the exact same problem. Tried using ptvsd 3.0.0, 4.2.6 and 4.2.7. After extensive troubleshooting trying out all manner off different values for the two path mappings I can report that it seems as if ptvsd just concatenates both path values.

I am running a Flask app in a docker container. I am exposing port 8000 for the Flask app as well as port 5678 for ptvsd. My app resides in /app inside the docker container and on my host machine in a different path altogether.

My launch.json entry looks like:

       {
            "name": "Python: Docker Remote Attach",
            "type": "python",
            "request": "attach",
            "port": 5678,
            "host": "walaa",            
            "pathMappings": [
                {                    
                    "remoteRoot": "",
                    "localRoot": "${workspaceFolder}"                    
                }
            ]

        },

If I run my container I can start the Python: Docker Remote Attach config without any issues. The moment I add a breakpoint using the IDE the following error occurs:

pydev debugger: warning: trying to add breakpoint to file that does not exist: /app/c:/Users/adria/Projects/voila/src/Blueprints/location_bp.py (will have no effect)

I have also noticed that no matter what I set the localRoot and the remoteRoot values to the error message remains the same as if it totally ignores the values I set them to and using the default values only.

For instance, if I change my launch.json entry to the following:

        {
            "name": "Python: Docker Remote Attach",
            "type": "python",
            "request": "attach",
            "port": 5678,
            "host": "walaa",            
            "pathMappings": [
                {                    
                    "remoteRoot": "/somethingelse",
                    "localRoot": "${workspaceFolder}"                    
                }
            ]

        },

One would expect the error message to at least reflect the new remoteRoot value of /somethingelse but sadly this is not the case, instead the error message remains the same.

pydev debugger: warning: trying to add breakpoint to file that does not exist: /app/c:/Users/adria/Projects/voila/src/Blueprints/location_bp.py (will have no effect)

I have tried removing the pathMappings collection entirely, changing the *Root values to absolute paths, making both ".", making one "." and the other absolute, making both blank, one blank and the other either absolute or "." and all combinations of the aforementioned without any luck. Those values are happily ignored.

I have no idea if the VS Code extension is sending the incorrect information to the remote server or if the remote server's ptvsd is incorrectly interpreting the values it receives.

Any help will be greatly appreciated.

[fabioz]

I'll take a look at this.

[fabioz]

I've been able to reproduce this.

The problem I found is that if the localRoot set in the path mapping does not match the case of the file with the breakpoint exactly, things go awry.

This means that if the path mapping localRoot is set to something as the following on windows:

"localRoot": "c:\my\folder"

and later a breakpoint is sent as:

"C:\my\folder\my_file.py" (notice the different case on the drive letter)

then there will be no translation applied and when the debugger goes on to make that path absolute it'll end up concatenating the result with the working directory generating something as:

/home/cwd/C:/my/folder/my_file.py

The workaround for this would be making sure that the localRoot casing matches and use that value as the entry.

i.e.: if it fails with /home/cwd/C:/my/folder/my_file.py, set the localRoot to C:/my/folder and if it fails with /home/cwd/c:/my/folder/my_file.py, set it to c:/my/folder (notice drive letter case).

-- it seems that the ${workspaceFolder} doesn't always match the case of the paths with breakpoints sent to the remote later on, so, it can't be always used.

The fix I'll make so that this doesn't happen anymore is taking into account that the client is on Windows and then normalizing the cases of the paths sent from the client and in the path mapping (I don't know why on some cases VSCode sends the case for the ${workspaceFolder} different from the case of the breakpoints later on, but we should have enough information to work around it).

[erasmusa]

Thank you so much for taking the time to look into this. I have made the changes that you have suggested and it works like a charm!

Thanks again.

[DonJayamanne]

The workaround for this would be making sure that the localRoot casing matches and use that value as the entry.

Can't we somehow try to do this on behalf of the user.
I don't think issues will try the workaround. They just might give up.

E.g. piggy back to editor via an event or the like, along the editors for more information if necessary... Horrible workaround, basically thinking out loud to solve on behalf of user..
@karthiknadig /cc

[fabioz]

@DonJayamanne this is already fixed in the master branch (in: 9ec0b7a).

I'm not sure why this is happening so much now. My guess is that VSCode previously passed the drive with the same case for breakpoints and for the ${workspaceFolder} variable, but from recent reports this doesn't seem to be the case.

[filipski]

Thanks for working on this!
According to microsoft/vscode#72070 (comment) you should probably file a bug against VSCode.

BTW, when current workaround will be available in the ptvsd release?