Breakpoints are not hit anymore with PTVS 2.1RC

Sep 4 at 12:52 PM
Edited Sep 4 at 12:53 PM

I have upgraded PTVS from 2.1 beta 2 to 2.1 RC (Visual Studio 2012). In pure Python debugger, my breakpoints are not hit anymore with this version. More precisely :
  • In some of my python files they are hit once, and never hit again.
  • In some files, they are never hit.
These files do correctly appear in the Loaded modules window. Debugging has always worked fine with previous version of PTVS (I'm a user for about 2 years now), but now it is completely useless, at least for the debugging part.

I cannot tell you if it is better in mixed mode debbuging because it has never worked for me. I have to say that my scenario is quite complicated : custom Python interpreter (embedded) executing a GUI application ( mainloop, events, ... ) written in Python.
But as I said, I never had problems (for pure python debugging, mixed-mode is another story).
Can you please help me, I don't want to get stuck with 2.1 beta 2...

Sep 4 at 5:12 PM
Can you tell more about your configuration - in particular, which Python version is it?
Sep 5 at 8:26 AM
Thank you for your answer. My python version is 2.7.5. The problem appears with PTVS 2.1 RC on VS2012. I tried also on another machine, with the same python version and the problems are the same.

I tried launching the debugger using F5 or attaching to the existing process. In the latter case, the debugger is correctly loading and running, but sometimes after a breakpoint is hit, the debugger suddenly stops for no apparent reason... By stopping, I mean no error dialog is displayed or else but in VS I'm no longer in debug mode.

As I told you in my previous message, my configuration is kind of special because I have a GUI application entirely written in python scripts, with a main script which is the entry point. I use a custom Python interpreter (embedded) containing a lot of C++ modules that can be called from the Python layer (CPU-consuming tasks delegated to C++ kernel). The entry point script is executed by the custom interpreter to launch the GUI application (using PyExec_SimpleFile or something like this...).

Let me know if you need more information, or if you want me to test something.

Sep 5 at 8:56 AM
One thing that comes to mind is a weird bug that was reproducible on 2.7.5, but not on 2.7.7. However, that one involved mixed mode debugging. On the other hand, breakpoint implementation in both debug engines is similar in many ways, even if the code is distinct, so perhaps it affects both equally. Can you try updating to 2.7.8 and see if that helps?

It might also be worth looking into why mixed mode doesn't work for you in general. Your scenario should generally be supported - the only sticking point there is whether Python is linked dynamically, and how much have you modified the interpreter source code. If it's stock Python in terms of code, and you're linking dynamically, then it should work, and I'd like to figure out why it doesn't.
Sep 8 at 7:43 AM
I can not update to Python 2.7.8 because this is a lot of work to do. We have a huge number of external dependencies that rely on python so that would mean recompiling almost every of them ... Looking at the bug you are refering to, the "Step over", "Step into", and other debugging navigation does not work for me, and I'm pretty sure this is due to the main event loop involved in our GUI (any of these buttons is equivalent to hitting "F5", so continuing until the next breakpoint). If the main script passed to the custom interpreter is not GUI-related (no event loop triggered), then "Step over", "Step into", ... do correctly work.

About the mixed-mode debugging : it works, but simply the breakpoints in the Python layer are never hit. If I set a breakpoint in the C++ layer, I have a stack that shows frames like "<Unknwown>!PythonFile", "PythonFile" being the correct name of the Python module. Going to the scope of this frame, I have nothing in "Locals" and I am not able to watch anything.
Using F5 to start mixed-mode debugging, all Python files are properly loaded (even if this can take up to 10 min, since a lot of AttributeError exceptions are printed in the Output Window), but when a file containing a breakpoint is loaded, then a message is displayed like "The breakpoint can not be set in file <correct_name_of_python_file>". Same thing when attaching to existing process, even if in this case the loading of Python files is quicker...