Re: [cython-users] Runtime error in visual studio: cython wrapping a C++ class with virtual destructor

[Robert Bradshaw]

Don't have Windows myself, but I might try trying to reproduce this
error in a single function (that allocates then deletes the object)
and then into a (non-Python) example you could ask on visual studio
mailing lists.

On Mon, Oct 22, 2012 at 4:09 PM, Jasmine Sandhu
<sandhu....@gmail.com> wrote:
> Hi,
>
> I'm wrapping a C++ class that has a virtual destructor in the base class.
> The python/cython/c++ application needs
> to run on windows and Mac OS X.
>
> On Windows:
> -----------
> I compile the C++ into a DLL and link the cython extension with it. The
> compilation works fine;
> however, when I run the test, I get a runtime error in the Microsoft Visual
> C++ Debug Library:
> 'Debug Assertion Faled!'
>
> See error here: http://www.nimret.org/jasmine/stuff/DebugAssert_error.jpg
>
> The virtual destructor in the base class causes the problem.
>
> I have reproduced the problem in a simple example. The files are at:
> http://www.nimret.org/jasmine/stuff/
>
> The example:
> ------------
> 1. Base.cpp - base class with virtual destructor
> 2. Rectangle.cpp - derived class with over written destructor
>
> The cython (pyx) code is a wrapper around the Rectangle object.
> It instantiates Rectangle, defines python methods to wrap the C++ methods.
> At the end it deletes the Rectangle object.
>
> I've stepped through the debugger in Visual Studio and
> am also printing statments. The application seems to step through as
> expected:
>
> 1. base class constructor
> 2. derived class constructor
> 3. calls a method and prints output
> 4. Invokes __dealloc__ at the end of life
> 5. derived class destructor
> 6. base class destructor
>
> Then I get the 'Debug Assertion Failed!' error.
>
> On the Mac, I'm building the C++ files with the cython (pyx) all in one
> shared object.
> It runs and exits cleanly.
>
> Has anyone gotten virtual destructors to work in cython on the Windows side?
> This is currently blocking us in wrapping existing C++ code to use in
> Python.
>
> Thanks!
> Jasmine

[Jasmine Sandhu]

Thanks Robert,

We actually found the issue to be in the C-runtime library. I was using the flag /MDd which uses the debug version of the multithread, DLL specific version of the runtime library. Changing this to the non-debug version (/MD) works fine.

If I use only C++, so I have a console application with a main method that uses this DLL, either runtime library works fine in visual studio. However, the python/cython/C++ setup has this issue. Though I still don't know the exact problem, for us the fix is to use the non-debug version of the runtime library.

In cython, when we define a new C++ object, Python or Cython must be allocating memory for it. Closest explanation I found is that the same runtime library needs be responsible for allocating and deallocating the memory. The debug version allocates the requested memory plus some additional memory for book-keeping. So the debug runtime library maybe trying to delete this additional memory; however, since I'm not using debug versions of python/cython, they are likely using the non-debug versions of the runtime library, in which case, there is no additional memory for the debug version to delete. 

Jasmine

[Robert Bradshaw]

On Mon, Oct 22, 2012 at 9:20 PM, Jasmine Sandhu <sandhu....@gmail.com> wrote:

Thanks Robert,

We actually found the issue to be in the C-runtime library. I was using the flag /MDd which uses the debug version of the multithread, DLL specific version of the runtime library. Changing this to the non-debug version (/MD) works fine.

If I use only C++, so I have a console application with a main method that uses this DLL, either runtime library works fine in visual studio. However, the python/cython/C++ setup has this issue. Though I still don't know the exact problem, for us the fix is to use the non-debug version of the runtime library.

In cython, when we define a new C++ object, Python or Cython must be allocating memory for it. Closest explanation I found is that the same runtime library needs be responsible for allocating and deallocating the memory. The debug version allocates the requested memory plus some additional memory for book-keeping. So the debug runtime library maybe trying to delete this additional memory; however, since I'm not using debug versions of python/cython, they are likely using the non-debug versions of the runtime library, in which case, there is no additional memory for the debug version to delete. 

Yep, that would explain exactly what's going on. Thanks for following up.