[Ipopt] Termination code 11
jakesson at control.lth.se
Fri May 15 14:55:10 EDT 2009
I tried with a fresh 3.6.1 - here are my findings:
- If I configure with --enable-debug the model solves as expected, that
is, no termination code 11.
- If I configure without --enable-debug I still get termination code 11.
- If I run valgrind, I get the following printout:
johan_013 at osiris:~/Optimica/TOC_0_3_1/optimica_examples/DoubleIntegrator>
valgrind --db-attach=yes ~/Ipopt/Ipopt-3.6.1/build/bin/ipopt bla.nl
==4141== Memcheck, a memory error detector.
==4141== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==4141== Using LibVEX rev 1854, a library for dynamic binary translation.
==4141== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==4141== Using valgrind-3.3.1, a dynamic binary instrumentation framework.
==4141== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==4141== For more details, rerun with: -v
==4141== Invalid write of size 8
==4141== at 0x806590E: la_replace (in
==4141== by 0x46314A7: ???
==4141== Address 0xa59f14be is not stack'd, malloc'd or (recently) free'd
I do not know what la_replace is - is it part of IPOPT? Please let me
know if you would like me to submit a bug report.
Andreas Waechter wrote:
> I don't think that there are any relevant changes from 3.6.0 to 3.6.1
> that might fix this issue...
> termination code 11 means that there is memory bug. Johan, I suggest
> you get a clean version of Ipopt (well, then you might was well take
> 3.6.1) and all dependencies, and reconfigure the same way as you did
> before, just add "--enable-debug" to the configure command line. Then
> do the usual make test and make install.
> Then see if you still have this problem. (If not, try again, but
> without --enable-debug.) If you still have this problem, you need to
> create an AMPL input file (*.nl) so that you can run the Ipopt AMPL
> solver from the command line. To do that, just add
> write gbla;
> before the solve command in your AMPL script. This should create a
> file "bla.nl". Then try to run
> ipopt bla.nl
> from the command line, and hopefully you will still see the error.
> Now you can run Ipopt through a debugger or better, a memory checker,
> as in
> valgrind --db-attach=yes ipopt bla.nl
> This will tell you where the memory problem appears. Maybe you can
> already see then what the problem is. If you can't please submit a
> bug ticket at the Ipopt mailing list describing exactly you problem
> (and what OS and compilers you are using), and attach the
> Ipopt/config.log file (in the Ipopt subdirectory!) and the files
> necessary to reproduce this problem.
> On Fri, 15 May 2009, Ashutosh Mahajan wrote:
>> 3.6.1 is also available. the release didnt seem to be announced on
>> the mailing
>> list. the issue might have been fixed there.
>> On Fri, 15 May 2009, Johan ?kesson wrote:
>>> I just compiled Ipopt 3.6.0 (with MA27) on an OpenSuse 11 system.
>>> Compilation went went without problems and I can run the tests (make
>>> When I run the freshly compiled Ipopt executable with AMPL I get an
>>> error with some models, for example
>>> > ampl DoubleIntegrator.run
>>> Ipopt 3.5.4: max_iter = 10000
>>> error running /home/jakesson/Ipopt/Ipopt-3.6.0/build/bin/ipopt:
>>> termination code 11
>>> The problem I try to solve is simple and solves easily on other
>>> platforms. A strange thing is that some models solve just fine with
>>> the very same Ipopt executable that gives termination code 11 in the
>>> example above.
>>> I have also tried to compile Ipopt 3.5.4 on the very same machine
>>> experience the exact same results.
>>> Ipopt mailing list
>>> Ipopt at list.coin-or.org
>> Ashutosh Mahajan
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
More information about the Ipopt