2
Vote

Stepping into ctypes call does not end up in C++

description

I'm using Python Tools for Visual Studio Express 2013. I can't do the c++ debugging of an extension. I've already enabled native code debugging. My doubt is how to link the 2 projects (c++ and python)? The c++ library is loaded in this way in python (3.4 - 64bit):
cpplib = ctypes.cdll.LoadLibrary(CPPLIB_PATH)
During the debugging I arrive to this point in the python execution:
def update(self, dtrain):
        """ update """
        assert isinstance(dmatr, DMatrix)
        cpplib.Update( self.handle, dtrain.handle )
then I see that Visual Studio opens init.py
 def __getattr__(self, name):
        if name.startswith('__') and name.endswith('__'):
            raise AttributeError(name)
        func = self.__getitem__(name)
        setattr(self, name, func)
        return func
and finally it opens the disassemby instead of a proper c++ debug environment... :-(

Screenshot of call stack: http://snag.gy/AFkis.jpg

file attachments

comments

giuliohome wrote Aug 11 at 9:41 AM

You can find also other comments in my question on SO

pminaev wrote Aug 11 at 3:46 PM

In SO comments, you mentioned that you have a C++ breakpoint on the other side. Does it show up as bound (i.e. solid red) in VS before stepping in?

Also, you mentioned that trying to step through that thunk landed you somewhere inside clr.dll machinery, and that one of the functions is IJWNOADThunk::FindThunkTarget. Is the DLL that you're trying to call compiled with Managed C++, or with C++/CLI?

giuliohome wrote Aug 11 at 4:46 PM

The C++ dll is compiled with VS Express 2013.
BP is not solid if debugger support type is auto,
but if I change it to managed it becomes solid...
I assume I have cli/c++ but I'm not sure and
if you can point me to a brief example of code
that is called by python ctypes and it is debugged by PTVS,
I would appreciate and double check everything :)

pminaev wrote Aug 12 at 11:40 PM

This does seem to indicate that it is managed.

Note that if you're attaching to your process using automatic code type detection, it will default to "Python" only, so you won't be debugging C++ at all. To enable mixed-mode, you must manually check "Python" and the other code types that you want to debug - but, at the very minimum, you always need "Native" to be checked. So in your case, if the DLL is compiled as native, then you need to select Python+Native. If it's compiled as managed, then you need to select Python+Native+Managed.

giuliohome wrote Aug 13 at 1:01 AM

Find attached the debugger types available on Visual Studio Express 2013:

only native
only managed
mixed
automatic
script
only gpu

I think I've tried more or less all of them many times...
Sorry, I can't see the possibility to select Python+Native+Managed.
Please help, thanks

giuliohome wrote Aug 13 at 1:06 AM

Image

pminaev wrote Oct 1 at 3:15 AM

This will only work when attaching to a process via Debug -> Attach (you can select whatever debug engines you want there). When launching a process, you are limited to the debug engines that this particular project system (in your case, C++) saw fit to list.

giuliohome wrote Oct 1 at 4:18 AM

I remember that in facy I could step into c++ when attaching to the process.
But this is something that would work even without pytools, wouldn't it?
Furthermore it appears that python3 code is not in the call stack so actually I could not step from python to c++ ...

giuliohome wrote Oct 1 at 4:22 AM

I meant "in fact" (sorry for the typo) I could break into c++ (but not passing from python 3 64bit code to c++ code)