Wrong Results Under Debug x64 Mode

[breezeBIT]

There are different behaviors between debug x64 and release x64 modes for the precompiled windows package version 2.0. For example, suppose you want to evaluate sin(1.0) using DA method and the codes are as follows:

#include
#include "stdafx.h"
#include <DA/dace.h>

using namespace std;
using namespace DACE;

int main(void)
{
DA::init(24, 1);

DA x = DA(1);
DA f = sin(x);

double y = f.evalScalar(1.0);

cout << "DA result is: " << y << endl;
cout << "Exact value is: " << sin(1.0) << endl;

return 0;

}

Suppose the Visual Studio 2017 is used, after compiling and linking, the variable y will have the wrong value 0 under debug x64 mode while it will have the right value of about 0.841471 under the release x64 mode.

[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.