Mixed mode debugging, when Python interpreter is embedded

Feb 18, 2015 at 9:00 AM
Hello, all!

I want to debug my python scripts, called from .exe, written in C++.

Is it possible with PTVS mixed mode debugging feature?

Regards,
Artem
Coordinator
Feb 18, 2015 at 4:57 PM
Yes, absolutely! Just attach to your .exe and be sure to specify the code type explicitly, and select both C++ and Python.
Feb 23, 2015 at 4:07 PM
Edited Feb 23, 2015 at 4:23 PM
I try to debug my python calls from C ++, but breakpoints in python code are inactive. The python call itself performs well, I'm getting the data what I expect.

Software:
Python 3.3.5 32 bits
Visual Studio 2012

Debug Symbols - downloaded here http://pytools.codeplex.com/wikipage?title=Symbols%20for%20Python%20mixed-mode%20debugging
and placed at C:\Python33\symbols

Symbol folder was added to VS (Tools/Options/Debugging/Symbols)

PythonApplication native code debugging was enabled

C ++ code:
#include "Python.h"
#include <iostream>
using namespace std;


int main(int argc, char *argv[])
{
 Py_Initialize();

 // Добавим путь к скрипту 
 PyObject* sysPath = PySys_GetObject((char*)"path");
 PyObject* programName = PyUnicode_FromString("C:\\Dropbox\\python\\Mixed_Mode_Minimal\\PythonApplication1\\");
 PyList_Append(sysPath, programName);

 PyObject* pName = PyUnicode_FromString("module3"); 
 PyObject* pModule = PyImport_Import(pName); 
 Py_XDECREF(pName);

 PyObject pFunction, pArgs, *pResult;

 pFunction = PyObject_GetAttrString(pModule, "function"); 
 Py_XDECREF(pModule);

 pArgs = PyTuple_New(2); //new
 PyTuple_SetItem(pArgs, 0, PyLong_FromLong(4));
 PyTuple_SetItem(pArgs, 1, PyLong_FromLong(5));
 pResult = PyObject_CallObject(pFunction, pArgs); 
 Py_XDECREF(pFunction);
 Py_XDECREF(pArgs);

 int One, Two;
 One = PyLong_AsLong(PyTuple_GetItem(pResult, 0));
 Two = PyLong_AsLong(PyTuple_GetItem(pResult, 1));
 Py_XDECREF(pResult);

 cout << One << endl;
 cout << Two << endl;

 PyRun_SimpleString("print('runned')\n" "input()");

 Py_Finalize();
}
Python code is very simple:
def function(x, y):
 return (x + y, x * y)
Mar 10, 2015 at 5:47 PM
Guys, help me, please!
Coordinator
Mar 10, 2015 at 5:54 PM
Sorry for not getting back to you earlier - notifications of new comments get lost sometimes.

Can you tell more about how it is not working for you? Is it just breakpoints, or do you get no Python debugging at all? E.g. if you put a breakpoint somewhere in your C++ code, do you see [Python view] nodes on PyObject variables?
Mar 10, 2015 at 6:37 PM
In C++ code our breakpoints are work normally.
We put breakpoint in Python code:
def function(x, y):
/*breakpoint*/ return (x + y, x * y)
And we go without stopping on breakpoint.

We want invoke a function named "function" from Python code and stop.
Coordinator
Mar 10, 2015 at 7:17 PM
When you stop on a breakpoint in C++ code, on the line with PyObject_CallObject, do you see Python modules in the debugger Modules window (Debug -> Windows -> Modules)? Also, if you expand, say, pArgs in the Locals window at that point, do you see a child named [Python View] on it?
Mar 10, 2015 at 7:33 PM
Edited Mar 10, 2015 at 7:34 PM
When you stop on a breakpoint in C++ code, on the line with PyObject_CallObject, do you see Python modules in the debugger Modules window (Debug -> Windows -> Modules)?
Yes, i see python33_d.dll
Also, if you expand, say, pArgs in the Locals window at that point, do you see a child named [Python View] on it?
No, i can't see child named [Python view]
Coordinator
Mar 10, 2015 at 7:52 PM
I rather meant Python modules (as in, .py files). But it looks like you don't get Python debugging to kick in at all.

python33_d.dll is a debug version of the interpreter. Did you build it yourself? If so, then you'll need to use the symbols produced by that build - the ones that you can download from python.org will only work for binaries installed from there, if you build the DLL yourself, they won't work for it.

(If you do indeed have a symbol mismatch problem, then you should be getting a message box telling you that you don't have symbols when you start debugging.)

Also, can you describe how you're starting debugging? You said that you have set the "Enable native debugging" checkbox on the Python project, but looking at your code, it seems that your entry point is actually the C++ project. If you have the C++ project set as a startup project, and just use Start Debugging (F5), you won't get Python debugging - C++ projects are not aware of Python. The "Enable native debugging" setting on the Python project is not used at all in that case, it is only relevant when your startup project is the Python project.

If your startup project is C++, then you have to run it without debugging, and then attach via Debug -> Attach to Process, and manually select Native and Python code types in that dialog. You might also want to add something like getchar() to your C++ code so that it pauses and allows you to attach.
Mar 10, 2015 at 9:11 PM
python33_d.dll is a debug version of the interpreter. Did you build it yourself?
Yes, i build it.
If i want to use your symbols what i must to do?
Also, can you describe how you're starting debugging?
Yes, my entry point is C++ project.
If your startup project is C++, then you have to run it without debugging, and then attach via Debug -> Attach to Process, and manually select Native and Python code types in that dialog. You might also want to add something like getchar() to your C++ code so that it pauses and allows you to attach.
Yes, it works!
Maybe it have another solution if my startup project is C++ and i invoke Python code?
Coordinator
Mar 10, 2015 at 11:26 PM
Right now we don't have a better solution for C++ hosts. Go ahead and file a feature request; we haven't really looked much into this, but it may be that the C++ project system can actually be extended to add a property that would enable Python debugger when running with F5.

For symbols, unfortunately, the way VS works with them (in general, not just for Python) is that the symbols must match the build exactly - i.e. even if you're rebuilding the same exact source code, byte-for-byte identical, it will still produce different symbol files, and they can only be used with the build for which they were generated, and no other. So there's no way to have symbols downloaded from python.org work with your own build of Python; you have to use the symbols that are produced as part of that build. If you are running on the same machine on which you've built Python, it all should just work. But if you're giving that Python build to someone else, make sure that you copy the .pdb files alongside the .dll.