[Solved]Pycharm remote debugging local file not updating

已完成

Tried to restart PyCharm and everything's alright.

-----

Hi, I'm using Pycharm 2016.3 Professional edition's remote debugging. However, something weird happened.

After I modified local files and upload to remote servers, I tried to remote debugging using the remote interpreter. But when I stepped into other function inside other files of my project, I found that the files were located at local path such as ~/.PyCharm2016.3/system/remote_sources/-1117781397/-12687924/path/to/my/file but it was not updated to the newest.

To make sure I did sync files to my remote server, I ssh to the remote server and make sure that the files have changed correctly.

Also, I tried to use the remote interpreter to run my code, whose result was correct which differed from what using remote debug.

So I want to know is there something wrong or do I have a method to update local caches of remote files? Please forgive my poor English and I am looking forward to some help.

5

Why is this marked as solved?
This is happening in 2017.3.
It runs the correct code but debugs old, wrong code, in remote_sources.

1

I've been seeing this repeatedly with both profiling and debugging, using PyCharm Professional 2018.3.

After manually uploading and/or synchronizing via the Deployment menu, both on individual files and the entire project, the debugger and profiler still run old code.

I somehow managed to get the profiler running current code, but now the debugger is using old code.  It'll pull up local files, but line numbers are mismatched and not all breakpoints get set.

BTW, the settings between the run configuration (working directory, script path) and deployment (root path and mappings) are non-intuitive and not obviously connected.

5

Manually removing ~/Library/Caches/PyCharm2018.3/remote_sources/* and restarting seems to have updated at least one file, but other subsequent execution is using out-of-date files.

0

Hi, please try File > Invalidate caches/restart

If that doesn't help, can you please provide your project interpreter and run/debug configuration screenshots, including all the path mappings ?

-1

Hi, the issue is still actual in release PyCharm Professional 2019.1. I configured new working environment, integrated with Vagrant. The only mapping is the whole my local workspace and the workspace on remote (vagrant) instance.

When I make changes to some modules I see the update on remote but debugger points me on cached version in "remote_sources" which is outdated. I cleaned the cache, restarted PyCharm, so the modules were updated but on next change I reveal the same thing.

Please advice if there is any config that worth to look at

3

@Peterzdeb

Please attach a screenshot of your Run/Debug configuration and another one showing the problem.

0

Hi Sergey,

 

Attached the screenshot with run/debug configuration. Unfortunately I can't share the screenshot with code that represents the issue.

The workflow is:

  1. I modify code - add few lines of code in one module
  2. Add breakpoint for debug
  3. Check the file remotely in Vagrant, it has the change after file is saved
  4. Run Debug from PyCharm
  5. Debugger stops on the breakpoint, but shows me cached version of the module (not the module where I added the breakpoint). this cached version doesn't contain the newly added lines of code so the line highlighted is incorrect

Debugger points me on file in this location: /Users/petro.zdeb/Library/Caches/PyCharm2019.1/remote_sources/-281485427/-1651854169/tests/test_db_wrappers.py

0

Hmmm, that's interesting.

Do you have any deployment configurations for the project? In particular, do you deploy your project files to that vagrant box?

Please share another screenshot showing your Project Interpreter and its Path mappings.

0

By the way, does it happen only with pytests/certain files or you can reproduce it with some test file and minimum code?

0

Hmm, seems it happens only for run with pytest. When I run the debugger in normal Python mode and Vagrant, it allows me to debug original file (not the cache)

0

I couldn't reproduce it. Did you install your modules as editable to your interpreter?

remote_sources are the packages installed to your project interpreter and downloaded by PyCharm to have a local copy of them.

2

I had a similar issue. I was debugging a python application installed (non editable) inside of a docker container.

I started the debugger by right-clicking on one of the files on my host machine.

What I did not expect (even though I should have), the imports then referenced the installed files within my docker container and not the changed ones on my host machine.

I resolved it by:

-> rebuilding the docker container & invalidating my pycharm cache

Thans @Sergey Karpov for pointing me in the right direction (remote_sources).

 

0

Having the same problem with WSL. I'm trying to modify a library that's not meshing well with my code, but the debugger uses a cached version of my library after I edit it while using the debugger. No fix found yet?

1

I am having similar issues debugging locally with the latest version 2019.1.3 CE. Everything was fine until I found some bug in my code. I edited the file by adding some lines. Now, the debugger stops in the right breakpoints but follows the logic of the old code. I tried "File>Invalidate Caches / Restart ..." But this hasn't solve the problem at all. I tried adding multiple breakpoints but the debugger still follows the old file's logic. Any solutions?

1

@Harvybcn Please ensure you have uploaded the files using Tools > Deployment > Upload to...

And that automatic upload is enabled in File | Settings | Build, Execution, Deployment | Deployment | Options

-2

@Andrey-Resler I am not using remote debugging, I am using Local debugging, hence I have nothing to upload anywhere. I already tried manually removing some files from ".idea/" folder but no success so far. Funny enough, the same is happening now with Pycharm 2018.1.3 CE, which makes me think that 2019.1.3 corrupted the project files some how but I don't know which one. I am trying now to get a new fresh project and copying the code manually.

0

@Andrey-Resler Yes, I did. Unfortunately that didn't work either.

I found a hackey solution that might be useful for people. Basically, edit the temporary file. Then open the terminal and run the script I posted below. The idea is that you replace the actual library file in your filesystem with the temporary one you're editing after you make your modifications. It solves the most annoying problems and makes the workflow as you'd expect it for the most part. This is WSL specific solution, but I'd expect if you're working on a remote server the same idea would apply. Make a script that transfers the edited file to the remote before you launch your debugger every time and you should be golden.

The problem I'm running into now is that I can't open projects that are located purely in WSL, and not on my /mnt/c/ directory. VSCODE seems to work, and I can call pycharm on anything in /mnt/c, but not in WSL. This makes it so that even though I can edit through some temporary files and continue with my debugger remotely, as soon as I try to get into a file that isn't in my temporary directory the debugger stops :(. Any suggestions on how to handle that? If so, that would essentially provide a workaround for this bug in practice until a more concrete fix is presented

 

#!/bin/bash

# Used to push modified library files to remote_resources
# Will allow faster debugging of external libraries with pycharm

bilby='/home/alex/anaconda3/envs/myenv/lib/python3.6/site-packages/bilby/gw/'

pycharm='/mnt/c/Users/Alex/.PyCharm2019.1/system/remote_sources/1045508341/555082905/bilby/gw/'

# Files to forward

file1='utils.py'

# Copy over the files

cp $pycharm$file1 $bilby

0

I meet this problem too,please solve it.

0

@Andrey Resler

0

I have the same problem, with Phpstorm, and between a local copy on a Windows system and a remote copy on a Centos 7.x system through Vagrant. Line numbers are out of sync, even though the comparison between local and remote files indicate no differences.

Please fix this.

 

Sorry, forgot to mention: Phpstorm 2019.2 on Windows 10, with Vagrant running Virtual Box. The fact that the same problem appears across two different Idea-based applications and different environments strongly suggests the problem lies with the platform.

 

One more comment: the trouble may be due to a (my) misconfiguraton of the Deployment package.

0

Running Professional 2019.2 on Ubuntu 16, having the exact same problem. This issue is *not* solved and should not be marked as such.

1

Running Professional 2019.1.3 on MacOS10.14, having the exact same problem. This issue is *not* solved and should not be marked as such.

0

Will I have solved it by add PyCharm Debug Config pathmap. As follow.

-1

Are you, by any chance, working on your own python package, which you installed using setup.py ?

3

Not sure who you are addressing exactly, but I am not. I do *have* my own python package that was installed using setup.py, but I'm just importing that like any other library. The actual file that doesn't sync is just a normal python project file.

0

@C Ravasio

This thread is growing bigger and bigger. Please report the issue to our tracker https://youtrack.jetbrains.com/issues/PY  describing your problem in detail and attach your idea.log file from Help | Show Log in...

0

Greetings from 2019/12/30, the problem is STILL unsolved. I stumbled into this issue with weird server behavior and took me a while to question myself what have I done wrong. 

Basically the same workflow like the others and also read about the workaround to sync the cache file myself as there are multiple "-random_numbers" folders under the ".PyCharm2019.3/system/remote_sources/-612333121/-23454112" route. (By the way, is that part of the problem here? Might be abnormally generating too many cache folders here?)

 

Please fix this the mighty team of PyCharm, remote debugging without tool/ with faulty tool is a nightmare.

Thanks in advance.

 

 

1

@Bbc-abc

Could you please file a ticket to our issue tracker as described above? Ideally, provide the steps for reproducing the problem.
We'll investigate.

0

请先登录再写评论。