Mapping files for a Remote debug session

Mar 27, 2014 at 11:14 PM

When remote debugging, I run the script outside of the source file.
I am in path: /src/
Source file is in /src/py1/

There are other directories in src... (/src/py2, /src/pt3 etc...)
I run the script from /src: ./py1/

This method does not work with the debugger.
When I set a breakpoint it hits but I cant debug...
A view is opened with a message:
the current stack frame was not found in a loaded module ptvs ....

If I remove the break point, no hit.

If I create a new python project setting using /src/py1 as root of the project the breakpoint hits and I get access to debug.

I couldnt find any option to MAP the project.
The debugger think /src/py1 is the root when its not, for me...

How can I override this behavior?

Mar 27, 2014 at 11:14 PM
pminaev Thu at 11:53 PM
When you get the message telling you that "stack frame was not found", do you get an option to manually locate the source file in question somewhere? If you do, then once you open it, VS will remember the association.

If this option is not available, can you provide a screenshot of what you're seeing at that point? It might be better to move the discussion to our forum ( to keep it in its own thread and for easier reply tracking.
Mar 27, 2014 at 11:26 PM

I dont get any pop up or file dialog.

Mar 27, 2014 at 11:29 PM
Does the Call Stack window show the appropriate stack, including filenames?

Also, there is a Modules tool window that is hidden by default, which you can show via Debug -> Windows. It lists the modules (in this case, Python source files) that VS believes to be loaded in the process. Is your script in that list, and if so, what's its path as displayed there?
Mar 27, 2014 at 11:46 PM
The call stack shows the function names and file (module) name...

start in module1 line 30

As far as I can tell, its a complete stack...

As for modules, the sciprts i am using are not there...
Mar 27, 2014 at 11:49 PM
Also, it might help, I dont know...
Bu the Debug Interactive windows shows this:
Python debug interactive window. Type $help for a list of commands.
Invalid thread id '1'.
Mar 27, 2014 at 11:52 PM
It sounds like you're on PTVS 2.0. Can you try 2.1 Alpha, or (ideally) the most recent dev build? It has a number of bug fixes that relate to remote debugging in particular, like #1924 / #1953 - I wonder if that is what you're hitting.

If this doesn't help, then the other possibility is that this is #1923, for which I have not been able to update a repro so far. If that's the case, can you use the debugger Watch window to see what the __package__ is when you're stopped at the breakpoint?
Mar 28, 2014 at 12:50 AM

I did have 2.0, I updated to the lastest dev.

Now I have the script in the modules but its not loaded, the path is actually the linux path
Mar 28, 2014 at 1:08 AM
So you're getting the same exact problem - same error message - and the only difference is that it is in Modules?

Can you check __package__ for your frame when stopped at the breakpoint (you might have to use the Watch window for this rather than Debug Interactive).
Mar 28, 2014 at 1:22 AM
Edited Mar 28, 2014 at 1:28 AM
When I hit debug but cant see the file the module is actually the right one...

I see the package name without the file... e-g if im in a\b\ i will get a '___package___' "a.b"

Funny thing is that PTVS wont recognize a package name from its child.
Example: if im in a\b\ and in i`ll write "import b" it will fail, only "import a.b" will work....
Mar 28, 2014 at 1:48 AM
Ah, so the module that doesn't open is in a nested package? i.e. its __package__ always has one or more dots? Sounds like another case of #1923 to me...

Does it work if you try setting a breakpoint in a module with only one level of nesting (i.e. the one that is directly under a, rather than under a\b)?

With respect to how import works, are you using Python 3.x, by chance? It changed the behavior so that imports are always absolute by default, starting from the root regardless of where the importer is in the package hierarchy - you need to use from .. import b.
Mar 28, 2014 at 1:56 AM
Absolute imports are the default in Python 2.7 and you get warnings in 2.6. We used to have some weird analysis approach that was always wrong here, so I fixed it to the modern behavior.

That shouldn't affect debugging though.
Mar 28, 2014 at 2:08 AM
I just did a test.

If I run 'a\b\' and from call to a module b1 in a (a\
it will hit a breakpoint in and display __package__ as None.

As for imports, I`m using 2.7 and its set in the project as well (as in PTVS defaults)
Mar 28, 2014 at 2:30 AM
Edited Mar 28, 2014 at 2:31 AM
Zooba wrote:
Absolute imports are the default in Python 2.7 and you get warnings in 2.6. We used to have some weird analysis approach that was always wrong here, so I fixed it to the modern behavior.

That shouldn't affect debugging though.
I read the document and it says:
refers to a top-level module or to another module inside the package. As Python's library expands, more and more existing package internal modules suddenly shadow standard library modules by accident. It's a particularly difficult problem inside packages because there's no way to specify which module is meant. To resolve the ambiguity, it is proposed that foo will always be a module or package reachable from sys.path. This is called an absolute import.
So if a module/package is accessible from sys.path it should have IntelliSense in PTVS.

In my case, I set "sys.path.insert(0,'xxx'" at runtime to support this.
I tried adding it to "Search Paths" but it didnt work...

I`m new to PTVS so I dont know if im doing it right...
Mar 28, 2014 at 2:43 AM
Note that if you see a runtime exception about your import, then PTVS is not involved here at all (especially when you're launching the script yourself and then attaching to it, so normal PYTHONPATH is used). What Zooba referred to is the code analysis for those imports (which affects things like code completion and refactoring) - this is the part that is handled by PTVS.

The document predates Python 2.7 (it was written when 2.6 was still being planned). However, in this case I think it doesn't actually matter. Implicit relative imports allow you to import a sibling package - i.e. if your script is in a a\b\, and there's a\b\, then you can do import d from and it'll work (in 2.x). But it doesn't do anything special for the parent package - i.e. you can't say import b from You have to either do import a.b, or from .. import b.
Mar 28, 2014 at 2:45 AM
Regarding your original issue, I'll try to repro it on my machines and investigate. Since we already have bug #1923 describing this problem, I'll use that to track progress - I suggest you subscribe to updates for it to keep an eye on when it's fixed (there's a checkbox at the end of the page there).
Mar 28, 2014 at 3:49 AM
Mar 28, 2014 at 6:07 AM
For IntelliSense we don't try and handle runtime modifications to sys.path. If you want to add a path, adding it as a Search Path in Solution Explorer is the supported way. Unfortunately, this means that if you can't know the path before your program runs, there's really no way to get completions.