Search code examples
c++exceptionoctaverelease-modedebug-mode

Release mode works fine but debug mode gives unhandled exception- using Octave DLLs


Release mode works fine but debug mode gives me this:

Unhandled exception at 0x0fc5edac (msvcr90d.dll) in Executable_to_LinkDLL_to_FDDDLL.exe: 0xC0000005: Access violation writing location 0xbaadf00d.

I'm using Octave release DLLs. The exception is shown below. I was wondering if anybody ran into this problem.

enter image description here

enter image description here

enter image description here

Here is where error happens in my code (based on following call stack):

Here is where error happens in my code

enter image description here


Solution

  • Looking at the Octave documentation for string_vector, references to std::string are used. This implies that the Octave library needs to be built for the compiler and settings you're developing in.

    The reason is that classes such as std::string need not be binary compatible with another version of std::string. When you used a release build in a debug version, the internals of std::string are different in release and debug versions.

    However, even if the versions of std::string would be binary compatible, you have the issue of making sure that the Octave DLL and your application use the same runtime heap. The reason is that std::string uses dynamically allocated memory, and must use the same heap for both DLL and application. To ensure this, the DLL version of the Visual Studio runtime library must be used (/MD or /MDd compiler flags must be set for release or debug version of the DLL runtime, respectively).

    So you have two issues:

    1. Binary compatibility between versions of std::string between the Octave DLL and your application, and

    2. Making sure that the DLL and the application are built to use the DLL version of the runtime library to ensure the same memory heap is used.

    Your solution of using char * only avoids the std::string references and objects from being passed. I don't know how solid this solution is, since it seems it would be very easy to make a mistake and call a std::string function at some point.

    I would just ensure that the proper DLL's are used when developing and deploying your application. That is exactly what Microsoft does with its DLL's -- you can't mix and match release and debug versions of the Microsoft DLL's in your application, so the same applies here. The only time when you can mix/match release and debug DLL's is if the DLL only uses "simple" types such as DWORD, LONG, TSTR, etc. or pointers to these types for parameters and return values.