0

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

Megidd
  • 7,089
  • 6
  • 65
  • 142
  • I'm using many release DLLs from Octave... – Megidd Aug 07 '14 at 20:36
  • @drescherjm Could it be using release DLLs from Octave libraries? – Megidd Aug 07 '14 at 20:37
  • 1
    Unless they isolate allocations / deallocations you may have a problem with using more than 1 independent heap. Remember you can not allocate memory in 1 heap and free it in a different heap. – drescherjm Aug 07 '14 at 20:37
  • @drescherjm So I feel like I can't use Octave release DLLs in debug mode. Is there any solution for this. Because somebody else wants to use my MSVS2008 projects in her project, and the problem is that she wants my project to be in debug mode not in release mode. – Megidd Aug 07 '14 at 20:40
  • When you use Octave do you ask the dll to create and delete objects for you instead of using new / delete in your application? – drescherjm Aug 07 '14 at 20:43
  • @drescherjm Yes, I don't use any new/delete... – Megidd Aug 07 '14 at 20:45
  • Then I believe you are safe to use it. The .dll isolated you from this type of heap corruption. – drescherjm Aug 07 '14 at 20:49
  • 1
    @user3853917 - Release DLL's can be used in debug builds. This is the case if the release DLL does not attempt to pass or accept objects that handle dynamically allocated memory. I don't know Octave, but if the Octave API uses simple parameter types such as LONG, DWORD, etc. then the issue is not the DLL. – PaulMcKenzie Aug 07 '14 at 20:51
  • @drescherjm I added a new picture which shows this error happens when I want to use Octave as "embedded" engine in my C++ code. In Locals there is "embedded" in the "src" – Megidd Aug 07 '14 at 20:51
  • @PaulMcKenzie I added a new picture which shows this error happens when I want to use Octave as "embedded" engine in my C++ code. In Locals there is "embedded" in the "src" could it be that they are using "char*" to pass around the "embedded" ? – Megidd Aug 07 '14 at 20:54
  • 2
    @user3853917 - Well, the simple thing to look for is to see if Octave passes std::string back and forth between the DLL and your application. If so, then not only do you need the build types to match, you have to use the same compiler version that the Octave libraries were compiled with. That's the danger of passing back and forth objects such as `std::string` across module boundaries. – PaulMcKenzie Aug 07 '14 at 21:11
  • @PaulMcKenzie Thanks. That's a thing I should check, the call stack shows the `unsigned char*` is used, it might be std::string – Megidd Aug 07 '14 at 21:15
  • @PaulMcKenzie I think you got it. That's most probably because Octave is using `std::string` at DLL boundaries which is frustrating – Megidd Aug 08 '14 at 12:56

4 Answers4

3

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.

PaulMcKenzie
  • 34,698
  • 4
  • 24
  • 45
2

The debugger is picking up on a write to uninitialized memory that is silently being used by your program in Release mode. (I.e. in Release mode it's a disaster waiting to happen.) 0xbaadf00d is actually a sort of debugger message; see the relevant entry here.

Without seeing your code it's difficult to say beyond this what the problem is.

Edit: You posted debugging output referencing memcpy--so instances of memcpy in your code are one place to look obviously.

Matt Phillips
  • 9,465
  • 8
  • 44
  • 75
  • Thanks. when I follow the call stack, I see that this exception is happening inside the libraries which I'm using. – Megidd Aug 07 '14 at 20:42
  • @user3853917 I've never used Octave C libraries but I have a lot of experience with the GSL upon which I believe it is based--many of the functions there expect you to have allocated the memory yourself for e.g. a workspace and to pass it to the function as an argument. My guess is that you have passed a workspace or output argument which hasn't been allocated--very easy mistake to make. A problem intrinsic to Octave is less likely as it's a pretty mature product. – Matt Phillips Aug 07 '14 at 20:48
  • I added a new picture which shows this error happens when I want to use Octave as "embedded" engine in my C++ code. In Locals there is "embedded" in the "src" could it be that they are using "char*" to pass around the "embedded" ? – Megidd Aug 07 '14 at 20:56
  • @user3853917 Since `argv` is allocated I don't think the highlighted line in that image is your problem. – Matt Phillips Aug 07 '14 at 21:04
  • I'm not sure, following the call stack leads me to the highlighted line – Megidd Aug 07 '14 at 21:07
  • 1
    @user3853917 Ok then maybe the `()` operator is not doing a proper assignment. It's an unusual syntax anyway--I would look at the `string_vector` documentation and maybe try to find another way. – Matt Phillips Aug 07 '14 at 21:11
1

The windows LocalAlloc marks uninitialized heap memory with the value 0xbaadf00d. It looks like you are taking a pointer value from an uninitialized source and attempting to write to that memory location. While this may "work" in release mode, it is likely to cause memory corruption in a program that runs for a longer amount of time.

Beed
  • 460
  • 3
  • 10
  • Thanks. when I follow the call stack, I see that this exception is happening inside the libraries which I'm using. – Megidd Aug 07 '14 at 20:43
  • @user3853917 it may be that you are supplying it with an uninitialized parameter. I can't tell for sure without seeing the code. My advice would be to step through with a debugger and pinpoint exactly what call is crashing and what you are passing to the dll. – Beed Aug 07 '14 at 20:50
  • I added a new picture which shows this error happens when I want to use Octave as "embedded" engine in my C++ code. In Locals there is "embedded" in the "src" could it be that they are using "char*" to pass around the "embedded" ? – Megidd Aug 07 '14 at 20:55
0

I solved this issue by implementing the following piece of code. Instead of using string_vector class of Octave, now I'm using an array of char* like char*argv[2]={"embedded","-q"}; consequently the error was resolved but I ran into another error mentioned in this link: Octave c++ and VS2010

enter image description here

Community
  • 1
  • 1
Megidd
  • 7,089
  • 6
  • 65
  • 142
  • 1
    I added an answer to your question, also commented on your solution as far as how far it can go without getting into issues. – PaulMcKenzie Aug 08 '14 at 14:41