Memory Corruption Issue on Multiple Calls

[John Eddy]

I am having a memory corruption issue while using CSIPOPT in my code. I've boiled it down into a project that demonstrates the issue. It is a simple optimization problem. I've attached the project.  The issue occurs when I run it over and over in a loop. I linked against the pre-built 1.0.0 binaries. The stack trace is as follows:

at Cureos.Numerics.IpoptAdapter.FreeIpoptProblem(IntPtr ipopt_problem)
at Cureos.Numerics.IpoptProblem.Dispose(Boolean disposing) in C:\Users\anders.CUREOS\Documents\Visual Studio 2010\Projects\csipopt\src\IpoptProblem.cs:line 658

Any help would be appreciated.

Thanks!
John

[Anders Gustafsson, Cureos AB]

Hi John,

I notice that the error is in the Dispose method, so the error is maybe due to accidentally freeing an already freed pointer. I thought the csipopt code as it stands today would prevent such errors, but maybe there is a loophole after all.

Since you are deriving Solver from IpoptProblem, you might consider implementing your own void Dispose(bool disposing) method and override the corresponding base class method. That way you would have better control over the disposal procedure.

Best regards,

Anders @ Cureos

[John Eddy]

Hello Anders,

 

Thanks for the idea.  I can certainly override Dispose but I do have a concern.  I can't easily access the  m_disposed

and m_problem members of the base class (without using reflection).  So how could I do appropriate freeing of the m_problem?  I would not want to leak memory b/c I'll be creating very many solvers during the course of my application.

 

Thanks again,

John

[John Eddy]

I believe that I have come to a resolution on this issue.  I tried overriding Dispose and calling the base version conditionally but without success.  The only results I was able to achieve was either never calling the base class resulting in a substantial memory leak or having the same access violation problems.

However, in doing so I did notice that Dispose was only ever being called via the IpoptProblem destructor (Finalize) resulting in a value of False for the disposing argument in all calls.  That lead me to the idea of making my IpoptProblem subclass a much more temporary object and declaring it as the object of a using statement (in VB).  The result is that at the end of a solver, the runtime calls Dispose appropriately and finalization is suppressed.  So far, it seems to be working. I am not leaking memory nor am I having access violation problems.

I'll post back if anything changes.

Thanks again,
John

[Anders Gustafsson, Cureos AB]

Hi again John,

glad to hear that you have managed to find a solution, and really great that you could share it here as well.

Good luck with your optimization!

Best regards,

Anders