This project has moved and is read-only. For the latest updates, please go here.

Breakpoints disabled in Python code when running native debugging

Mar 3, 2014 at 7:35 PM
I tried to use Mixed-Mode debugging and managed to hit a breakpoint in the C++ code (which is great!), but not in the Python code.

After reducing the app to just a "print 'hello world'" python one-liner (no C++ at all), I still cannot hit a break point in the python code, if running with "Enable native code debugging" on. "Normal" python debugging works fine.

The breakpoint (on the very first line) displays a warning:
The breakpoint will not currently be hit. No symbols have been loaded for this document.

The Output windows displays:
'python.exe' (Win32): Loaded 'C:\Users\wolfpetr\AppData\Local\Enthought\Canopy\User\python.exe'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Users\wolfpetr\AppData\Local\Enthought\Canopy\User\python27.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\user32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\gdi32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\lpk.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\usp10.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\shell32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\shlwapi.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251\msvcr90.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\imm32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\msctf.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Windows\System32\sxwmon64.dll'. Cannot find or open the PDB file.
'python.exe' (Win32): Loaded 'C:\Windows\System32\ole32.dll'. Symbols loaded.
'python.exe' (Win32): Loaded 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\Python Tools for Visual Studio\2.1\Microsoft.PythonTools.Debugger.Helper.x64.dll'. Symbols loaded.
'python.exe' (Python): Loaded ''. Module was built without symbols.
The thread 0x2958 has exited with code -161611776 (0xf65e0000).
The program '[17284] python.exe' has exited with code 0 (0x0).
I also noticed one <unknown> in the Modules window, when the debugger runs.

I am using Win7, a 64-bit Canopy 1.3.0, Visual Studio 2012 Update 1 and tried both 2.0 and 2.1 releases of PTVS.

What could be the reason for this issue?
Why wouldn't debugging work, when the native mode is on?

Mar 3, 2014 at 8:33 PM
Can you see the module that you're trying to place a breakpoint in, in the Modules window and in Call Stack (when you break in C++)?
Mar 4, 2014 at 3:24 AM

as noted above, I can put a breakpoint in C++ and the debugger does stop there just fine.

The problem I am asking about actually happens even sooner and there is no C++ involved at all.

Just by switching from default to "native" debugging, all the breakpoints in the python code stop working, even in a plain vanilla python "hello world" project.

This seems strange, but I don't know what could be causing this.
Mar 4, 2014 at 3:57 AM
Mixed-mode debugger is a completely different implementation from the regular one, so it's no surprise that a bug affecting it would not repro when native debugging is disabled.

If you create a vanilla Python app that simply does an infinite loop with a counter, say like so:
x = 0
while True:
  x += 1
then run it with native debugging enabled, and hit Pause, what does the call stack look like, and do you see your file in the Modules window?
Mar 4, 2014 at 8:36 PM
Edited Mar 4, 2014 at 8:37 PM
I can see:
python.exe  D:\Canopy\User\python.exe   N/A N/A Symbols loaded. D:\Canopy\User\python.pdb   
<unknown>       N/A N/A Symbols loaded. 
kernel32.dll    C:\Windows\SysWOW64\kernel32.dll    N/A N/A Symbols loaded.
... [truncated] ...
Microsoft.PythonTools.Debugger.Helper.x86.dll   C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\Python Tools for Visual Studio\2.1\Microsoft.PythonTools.Debugger.Helper.x86.dll   N/A N/A Symbols loaded. 
Yet I am not able to step through or hit any breakpoints in the python code.

Where should I be looking for the cause of the issue?
Mar 4, 2014 at 8:44 PM
I'm trying to determine whether the Python debugger has actually kicked in or not. When the process is not treated as Python one for whatever reason (e.g. python*.dll symbols not loaded, or something else going wrong while initializing), you'll end up with just native debugging active, which would explain why C++ breakpoints work but Python ones do not.

The fact that you're seeing <unknown> in Modules means that Python debugger did load. However, if it did, then you should also be seeing .py (or .pyc) files in the Modules window - in particular, you should see your main module there. You should also be seeing your module in the Call Stack window if you break into debugger while that module is running (since breakpoints don't work, you'll need to use Debug -> Pause for that). If you're only seeing <unknown>, that may hint at where the problem lies.
Apr 7, 2014 at 7:37 PM
Edited Apr 8, 2014 at 2:40 PM
Actually, it turns out this works fine, when I use plain vanilla python form, downloading symbols manually as instructed in PTVS docs.

The issue only happens, when I use Canopy (in this case, version 1.3, 32-bit).

Is there any known problem with Canopy? Or a special setting that needs to be applied, other than setting the symbol path?
Jun 4, 2014 at 11:26 PM
Can you try this with Canopy 1.4?
Jun 5, 2014 at 10:08 PM

with Canopy 1.4, I can no longer reproduce the issue, so I'm happy.

But I also said that to Enthought and they're puzzled, because of no relevant changes were made in 1.4.
Jason McCampbell from Enthough suggested he'll discuss with the PTVS team.