SolveProblem_ExactHessian_NumberOfIterationsLessThanOrEqualToHessianApprox unit test failing in Debug/x86 mode about csipopt HOT 4 CLOSED

I used the 3.9.2 Ipopt DLL, debug, x86 version.

from csipopt.

There might be a problem with the Debug, x86 Ipopt DLL? The above unit test is now succeeding, whereas the SolveProblem_StandardOptions_OptimalObjectiveValueReturned is now instead failing (only in Debug/x86 mode) with the following report:

SolveProblem_StandardOptions_OptimalObjectiveValueReturned : Failed  
Expected: 17.014017299999999d +/- 1.9999999999999999E-07d
But was:  16.109692919198878d
at NUnit.Framework.Assert.That(Object actual, IResolveConstraint expression, String message, Object[] args)
at NUnit.Framework.Assert.AssertDoublesAreEqual(Double expected, Double actual, Double delta, String message, Object[] args)
at NUnit.Framework.Assert.AreEqual(Double expected, Double actual, Double delta)
at Cureos.Numerics.HS071NativeTests.SolveProblem_StandardOptions_OptimalObjectiveValueReturned() in HS071NativeTests.cs: line 64 

from csipopt.

Alternatively, the unit test is aborted altogether. The failure only seems to arise when running the unit tests as a suite (concurrency issues)? When running the unit test separately, it passes.

from csipopt.

The issue appears to be Ipopt*.DLL dependent. Have tested 3.8.1 DLL:s, and these do not yield any error in any configuration. The 3.9.1 DLL:s also yield no error in any configuration, except that x64/Debug results in C++ runtime error for most tests (interestingly enough not for the HS071 tests...)
Based on this investigation, I am urged to conclude that the issue is within the compilation of the Ipopt DLL:s and not csipopt. I will for now consider this issue completed. The recommendation is to use Release Ipopt DLL:s in production code involving csipopt.

from csipopt.