PTVS
PTVS copied to clipboard
microsoft
I get "Breakpoint in file that does not exist" when setting a breakpoint in remote Linux Python debugger
This issue has been moved from a ticket on Developer Community.
[severity:It's more difficult to complete my work] Hi guys, I have been trying to do remote Python debug from my Windows 10 PC to a Centos Linux PC. I can do the remote attach successfully, and I can step through the code, . The problem is that I cannot set a breakpoint in the code as I get a red circle instead of the red dot, and get the error "The breakpoint will not currently be hit. Breakpoint in that file does not exist". I have tried VS19 and VS22, and Python 3.7 and 3.9 but always get the same issue.
I also get a problem with VS22 that it reports "Import debugpy could not be resolved" but I don't think that's related as VS19 did not report this issue and it still had the same breakpoint problem.
Thanks, John
Original Comments
Feedback Bot on 11/20/2022, 08:10 PM:
(private comment, text removed)
Original Solutions
(no solutions)
When you're stepping through the code in VS, do you see the source code in the editor? And if so, when it shows the full path to the file while hovering over the corresponding editor tab, what is the path?
Hi Pavel, Many thanks for the questions. On my Windows PC the VS22 solution has the local version of the files open so I can see the code. I can also add this line to my local source: debugpy.breakpoint() When I attach to the remote process (which is looking at the same files through a network mount) VS22 will pause on the line after this point, and I can step through the code and step into functions. However I cannot insert breakpoints with VS22 as that is when I get "Breakpoint in file that does not exist".
When I hover over the tab it shows the local path (Windows), not the remote path (Linux). Let me know if you have any more questions or suggestions. Thanks, John
Just in case, can you double-check that the local and the remote source is identical?
Also, do you already have the source file opened in VS before you start debugging and pause on the line after breakpoint()? If you try to attach with no local .py files open, does it make a difference in behavior when stepping through code?
I have confirmed local and remote are the same files.
Up until now I have always had the local files open when debugging.
As you requested I tried closing all code tabs and then attaching to the remote process. VS opened up the local copy and showed it was pausing at the correct point. As it was still a local file it still won't me allow me to add a breakpoint.
I also opened up VS without a solution and attached to the process. This one showed it was pausing, but no code was shown in the GUI.
Thanks.
It appears that this is a manifestation of https://github.com/microsoft/PTVS/issues/6610, and it ends up half-working because VS got smarter and loads matching documents from the project when it can.
Hi Pavel, Thanks for the link to #6610. It doesn't look like there is much hope in getting this fixed in the short term, is that correct? Do you know when might it be addressed? Is it the case that this has never worked for anyone? I ask as the descriptions on the web on how to do remote Python debug imply it should have worked. Thank you.
At some point in the past, we used a different debugger. That one tried to match local filenames to remote ones automatically by walking the filesystem on both ends to reconstruct package names. This hasn't been a reliable approach since namespace packages became a thing, unfortunately.
I'd say that a short fix with UI specifically for this is probably unlikely, but there might be a cheaper workaround like exposing raw JSON for debug config, similar to VSCode. This is currently under discussion.
Hi Pavel, Thanks for the explanation, hopefully it's not too long before a solution can be implemented. I really appreciate the support. Regards, John
https://github.com/microsoft/PTVS/issues/7269 might be a good way to implement the raw JSON approach in a way consistent with other languages in VS.
Thank you for the report! Given our current limited resources, it's unlikely we will be able to fix this issue in the near future. We're closing it so we can focus on higher priority issues. However, if this is a critical issue for you let us know and we can reevaluate. Thanks!
