[Ipopt] terminate called after throwing an instance of 'Ipopt::RESTORATION_MAXITER_EXCEEDED' on SunOS 5.10
Drosos Kourounis
drosos at stanford.edu
Mon Nov 22 18:53:34 EST 2010
Hi all,
Whenever I had problems in some other architecture it was always a bug in mind code. Linux and Windows use (sometimes) to initialise allocated memory with zeros. This was not the case in Alpha machines running some weird operating system. So it was a problem of my code. I do not say that Ipopt has problems. But what I could suggest, is:
Run valgrind on Linux with
valgrind --leak-check=full --leak-resolution=high.
If everything is OK, then run again valgrind with --tool=
valgrind --tool=exp-ptrcheck --leak-check=full --leak-resolution=high
if again there are no error reports, you could use a native
Solaris application which does the same thing as valgrind and it
is found here:
http://www.oracle.com/technetwork/server-storage/solarisstudio/overview/index-jsp-138069.html
That will definitely catch this bug and tell you were it is. If you compile
Ipopt with debug information it will tell you also the line were it appears.
Good luck,
Drosos.
----- Original Message -----
| Hi Alex,
|
| Sorry, no idea then. I'm not working on Sun... Since it is working on
| other systems it does not appear to be an Ipopt code problem.
|
| Andreas
|
| On Mon, 22 Nov 2010, alex yu wrote:
|
| > Hi Andreas:
| >
| > This bug(?) is on SunOS 5.10 and Linuxipf. Linux and Windows have
| > no problem. The newest release has this issue too. For example on
| > SunOS 5.10,
| >
| > Exception of type class LOCALLY_INFEASIBLE is unhandled
| > t at 1 (l at 1) stopped in __exdbg_notify_of_throw at 0xffffffff7bc06390
| > 0xffffffff7bc06390: __exdbg_notify_of_throw : retl
| > Current function is
| > Ipopt::RestoFilterConvergenceCheck::CheckConvergence
| > 235 "Restoration phase converged to a point of loc
| > al infeasibility");
| >
| > Regards,
| >
| > Alex
| > On Mon, Nov 22, 2010 at 6:42 AM, Andreas Waechter
| > <andreasw at watson.ibm.com> wrote:
| >>
| >> Hi Alex,
| >>
| >> We are not really maintaining old versions of Ipopt. Have you tried
| >> if the problem occurs also with the newest release? (I just ran a
| >> problem that triggers this exception on my Linux setup and there is
| >> no issue.)
| >>
| >> Regards,
| >>
| >> Andreas
| >>
| >>
| >>
| >>
| >> On Fri, 19 Nov 2010, alex yu wrote:
| >>
| >>> Hi Andreas, and all:
| >>>
| >>> I am using Ipopt version 3.4.1. It works fine on Windows. However,
| >>> when I solved the same problem on SunOS 5.10 and Linuxipf, Ipop
| >>> fails
| >>> wiht "terminate called after throwing an instance of
| >>> 'Ipopt::RESTORATION_MAXITER_EXCEEDED' . Here is some debug info on
| >>> SunOS 5.10. Is this a compiler issue or bug?
| >>>
| >>> Thanks.
| >>>
| >>> Alex
| >>>
| >>> xception of type <unknown type> is unhandled
| >>>
| >>> t at 1 (l at 1) stopped in __exdbg_notify_of_throw at 0xffffffff7bc06390
| >>>
| >>> 0xffffffff7bc06390: __exdbg_notify_of_throw : retl
| >>>
| >>> wher: not found
| >>>
| >>> current thread: t at 1
| >>>
| >>> =>[1] __exdbg_notify_of_throw(0xffffffff7ffeac48,
| >>> 0xffffffff7ffeac30,
| >>> 0xffffffff78af7d40, 0xffffffff7bd0eea0, 0x106cd0, 0xfff
| >>>
| >>> fffff7bd10350), at 0xffffffff7bc06390
| >>>
| >>> [2] _ex_debug_handshake1(0xffffffff7bd105c0, 0x0, 0x1, 0x107ce4,
| >>> 0xffffffff7bd0eea0, 0xffffffff7bd101ac), at 0xffffffff7bc0
| >>>
| >>> 7240
| >>>
| >>> [3] _ex_throw_body(0xffffffff7bd105c0, 0x0, 0xffffffff7ffff080,
| >>> 0x107a34, 0xffffffff7bd10668, 0xffffffff7bd105c0), at 0xfff
| >>>
| >>> fffff7bc074e8
| >>>
| >>> [4] __Crun::ex_throw(0xffffffff7bd105c0, 0x1, 0x104f0cb60, 0x0,
| >>> 0xffffffff7bd10658, 0xffffffff7bd10228), at 0xffffffff7bc07
| >>>
| >>> 43c
| >>>
| >>> [5]
| >>> Ipopt::RestoFilterConvergenceCheck::CheckConvergence(0x1ca9dbfc0,
| >>> 0x104f0b7c8, 0x106116ca3, 0xffffffff7bd10648, 0x1ca8f
| >>>
| >>> 47c0, 0x2dc6c0), at 0x104f0ca84
| >>>
| >>> [6] Ipopt::IpoptAlgorithm::Optimize(0x1ca9dc7f0, 0x1ca8f4538,
| >>> 0x1ca8f43a0, 0x1ca9dc810, 0x104e9e9d8, 0x1ca9dc800), at 0x104
| >>>
| >>> e9f6bc
| >>>
| >>> [7]
| >>> Ipopt::MinC_1NrmRestorationPhase::PerformRestoration(0x1ca9dc8b0,
| >>> 0x1ca8f43a0, 0x1ca8f43a0, 0xffffffff7ffeed08, 0x1ca8f
| >>>
| >>> 43a0, 0x106509ed8), at 0x104f22814
| >>>
| >>> [8]
| >>> Ipopt::BacktrackingLineSearch::FindAcceptableTrialPoint(0x1ca9dcaa0,
| >>> 0x16cc400, 0x1ca9dcb78, 0x1060f591a, 0x0, 0x104e97
| >>>
| >>> 160), at 0x104e3e9d0
| >>>
| >>> [9] Ipopt::IpoptAlgorithm::Optimize(0x1ca9dd0a0, 0x1ca9da9d8,
| >>> 0x1ca9da9c0, 0x1ca9dd0c0, 0x104e9e9d8, 0x1ca9dd0b0), at 0x104
| >>>
| >>> e9f47c
| >>>
| >>> [10] Ipopt::IpoptApplication::call_optimize(0x1ca99c3d0,
| >>> 0x1ca99c3d0, 0x1060dea5d, 0x1ca6f7b78, 0x1ca99c3d0, 0xffffffff7c0c
| >>>
| >>> 93b0), at 0x104d95374
| >>>
| >>> [11] Ipopt::IpoptApplication::OptimizeNLP(0x1ca6f7b50,
| >>> 0x106dc2498,
| >>> 0xffffffffffbd490c, 0x42b400, 0x1ca6f7b68, 0x106509ed8)
| >>>
| >>> , at 0x104d948c4
| >>>
| >>> [12] Ipopt::IpoptApplication::OptimizeNLP(0x1ca6f7b50,
| >>> 0x1ca6f7ba8,
| >>> 0x1ca9da560, 0x1, 0x1ca9da3c0, 0xffffffff7fff2cb0), at
| >>>
| >>> 0x104d946f8
| >>>
| >>> [13] Ipopt::IpoptApplication::OptimizeTNLP(0x1ca6f7b50,
| >>> 0xffffffff7fff32b0, 0x252844, 0x1ca9da3b0, 0xffffffff7c0cc108,
| >>> 0x1c
| >>>
| >>> a6f7ba8), at 0x104d943c4
| >>>
| >>>
| >>> .
| >>>
| >>>
| >
| >
|
| _______________________________________________
| Ipopt mailing list
| Ipopt at list.coin-or.org
| http://list.coin-or.org/mailman/listinfo/ipopt
More information about the Ipopt
mailing list