2
Vote

Attach to embedded Python code in application

description

When attaching to embedded Python code in application, the breakpoints cannot be hit on one machine, but the other machine supports. The only major difference between two machines is VS 2013 Pro vs VS 2013 Ultimate with the latter working.

Also this requires trying different options of mixed-mode before this Python only mode starts working:

M2.0 + N + P
M4.0 + N + P
N + P
P

Then the Python Debug Interactive window works until certain evaluations in it detach it from debugging session. Immediate Window and Watch Window work.

comments

denfromufa wrote Jul 25 at 2:33 PM

This process above occasionally crashes VS 2013 Ultimate.
Even if it not crashes, then sometimes "detach all" and "stop debugging" do not work and the app has to be restarted.
Python only mode does not support stepping with F10 or F11, but only F5 with breakpoints work.

Zooba wrote Jul 25 at 2:47 PM

Do you have debugging symbols (.pdb files) for the embedding application and its python##.dll? If not, Python only mode is the only one that'll work. There should have been a dialog telling you to get symbols - did you see this? If not, it should have been fine.

What's the application? Is it public? Can we get a copy to investigate?

denfromufa wrote Jul 25 at 3:55 PM

Application itself is just a wrapper for DLLs. The wrapped DLL sequence ends up with 2 DLLs: one for embedded Python in C++/CLI and the other one for using it from C#. Application does not have symbols, the DLLs including python27.dll have symbols. The latter one you actually send me.

I sent very detailed log to ptvshelp(at)microsoft(dot)com before and we had some email trail with Pavel Minaev.

I'm going to check on providing our setup. Nothing from it publicly available.

The most reliable path so far is N+P or N+P+M, but these 2 options limit debug windows and speed of stepping through is very slow due to calls to libraries.

pminaev wrote Jul 25 at 4:18 PM

I would like to clarify this:
speed of stepping through is very slow due to calls to libraries.
Are you saying that it's slow because it steps into various native/managed functions that you don't want it to be stepping in? i.e., would an option to disable Python -> other stepping while using mixed mode be of interest?

pminaev wrote Jul 25 at 4:20 PM

Also, for the crashes, there should be crash reports in Windows Event Log, under Applications. Those include call stacks - can you share them here?

denfromufa wrote Jul 25 at 5:37 PM

Are you saying that it's slow because it steps into various native/managed functions that you don't want it to be stepping in? i.e., would an option to disable Python -> other stepping while using mixed mode be of interest?
I meant calls to Python libraries. Not sure about disabling Python -> other, because how do you go back to the other side (e.g N or M) of mixed-mode code that the developer debugs? Then just attaching Python only, makes more sense in my mind.
Also, for the crashes, there should be crash reports in Windows Event Log, under Applications. Those include call stacks - can you share them here?
This was sent before, but I'm re-sending it and even more again to your emails as a link, in case it was blocked before.

pminaev wrote Jul 25 at 6:15 PM

Ah, I see. The pure Python debugger skips calls into the Python standard library when stepping in; the mixed-mode one does not. That's a missing feature in the latter.

I've got the email and I'll look at this today.

pminaev wrote Jul 25 at 10:33 PM

One of the crashes seem to be from VS itself (AccessViolationException, and no code from PTVS in sight on the stack). If you've let it upload the WER report, VS Shell folk will take a look at it.

The other one is a bug in Debug Interactive attach code. It looks like we have a race there where we can potentially try to attach a REPL when a process is reported as created, but it doesn't have any threads associated with it yet. I'm going to fix that, but for the time being, if you find that you run into it a lot, I would recommend to close the Debug Interactive before the attach, and opening it only once attach is successful (specifically, you see at least one thread reported in the threads dropdown).

pminaev wrote Aug 5 at 9:31 PM

The debug interactive attach bug is fixed, and the fix will shop up in the next dev build (probably at the end of this week).

pminaev wrote Aug 15 at 5:04 PM

Den, can you try the RC build and see if debugging is stable for you now?

denfromufa wrote Aug 18 at 3:15 PM

Pavel, so all the issues that I reported related to debugging were fixed?

denfromufa wrote Aug 21 at 8:19 PM

I just tested with VS 2013 Express, 2.1 RC and most of the problems with mixed-mode debugging are still there for embedded Python now using PythonNET (not C++/CLI like before).

e.g.:
  • very slow stepping M+P+N, when gets to Python code;
  • only P mode is unstable - cannot detach, the app becomes locked
  • sometimes after detach or stopping debug, the app is not visible in attach list anymore, unless app is restarted
But now I can consistently attach using M+P+N or P only and stepping does not skip blocks like before.