Wrong Results Under Debug x64 Mode about dace

[abgandar]

I finally tried to have a look at this bug. I'm not very familiar with building on Windows, but I believe this is due to the subtleties of C++ DLLs in Windows.

How the DACE DLL is built (Release/RelWithDebInfo or Debug), determines which executables can link with it. This seems to be due to the passing of std:: classes between the DLL and the executable.

With a Debug package installed, building your code from the command line using cl /I "C:\Program Files\DACE 2.0\headers\include" test.cpp "C:\Program Files\DACE 2.0\lib\dace.lib", i.e. with release settings, causes the executable to crash with an out of bounds error inside the evalScalar() call. Debugging it, the problem is that the C++ interface between the code in the executable (evalScalar(), instantiated from a template), and the code in the DLL (eval()) don't seem to use the same interface. In the executable, a temporary std::vector objects created has the correct size (1), but once passed to the DLL, the DLL inside eval() sees them as size 0 and consequently crashes.

When compiling the executable with the same debug parameters as the Debug DLL
cl /I "C:\Program Files\DACE 2.0\headers\include" test.cpp "C:\Program Files\DACE 2.0\lib\dace.lib" /EHsc /Zi /RTC1 /MDd the code runs fine and produces the correct result.

Your problem is the inverse: When the DLL is built as Release, but the executable is built as debug, (as above), the error you describe happens. It is less obvious (as it doesn't crash), but I'm sure the problem stems from the same issue.

I played around a bit, and it seems the exact switch that breaks it is /MDd (something about multithreaded debugging). Compiling the executable without that, but the other debug switches mentioned above, yields correct results when linking with a non-debug DACE DLL.

In short, on Windows it seems the safest way to ensure correct results is to ensure the DACE DLL is only ever linked to the same build type used when building the DLL.
I don't know enough about Windows debug details to suggest a fix for this, although it seems many Windows system libraries come in different versions for the various debug options.

[abgandar]

Whoops, didn't mean to close this issue, but for the time being I don't think we'll have a solution.