[Ipopt] Ipopt crashes after switching to emergency mode

[Stefan Vigerske]

Hi,

I'm not sure what the callee-saved register says, I'm more familiar with 
looking at the stack trace.
In both cases, one is in function Ipopt::IteratesVector::z_L(),
which calls Ipopt::IteratesVector::GetIterateFromComp(4), which calls
Ipopt::CompoundVector::IsCompNull(4), which calls operator[](4) from an 
std::vector, and there it crashes.
So my guess is, that the vector is too short (<5 elements).
You could check this by configuring Ipopt with
   --with-ipopt-checklevel=1
This should enable more checks, esp. the one in IsCompNull() that checks 
that the index is in range (IpCompoundVector.hpp:78).
But if that has been verified to be the problem, I'm not sure what is 
causing it.

What exactly are the options you are passing to Ipopt?
Further, the warning "Least square initialization of x and s failed!" 
isn't something that usually comes up, maybe that should be 
investigated, too.

The error from trac may be from using some forbidden characters in the 
ticket message. Unfortunately, it's not clear which characters are not 
allowed.

Best,
Stefan

On 02/03/2015 03:48 PM, Jarkko Miettinen wrote:
> I am using Ipopt with MUMPS through jIpopt on OS X. The version is 3.11.9.
> When using a specific (not too large) set of data with my model using
> metrotha-algorithm, I get a segmentation fault every time.
>
> Number of nonzeros in equality constraint Jacobian...:     5560
> Number of nonzeros in inequality constraint Jacobian.:     1698
> Number of nonzeros in Lagrangian Hessian.............:     2085
>
> Least square initialization of x and s failed!
> Total number of variables............................:     1678
>                       variables with only lower bounds:     1678
>                  variables with lower and upper bounds:        0
>                       variables with only upper bounds:        0
> Total number of equality constraints.................:     1390
> Total number of inequality constraints...............:     1685
>          inequality constraints with only lower bounds:     1683
>     inequality constraints with lower and upper bounds:        2
>          inequality constraints with only upper bounds:        0
>
> ...
>
> iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du
> alpha_pr  ls
>   190  7.4376043e+03 6.07e+03 9.14e+22   4.8 1.60e+03  19.8 9.95e-01
> 6.80e-04h  1
>   191  9.2395614e+03 4.74e+05 1.18e+23  -5.1 1.18e+08  19.3 9.07e-01
> 6.61e-05h  1
>   192  9.1964024e+03 7.82e+03 1.18e+23 -10.2 2.45e+03  19.7 9.90e-01
> 2.46e-02h  1
>   193  9.1963215e+03 7.82e+03 1.18e+23 -11.0 1.57e+04  19.2 9.90e-01
> 3.81e-05h  1
>   194  2.5322626e+04 1.87e+06 6.10e+23 -11.0 6.72e+06  19.7 7.55e-01
> 3.55e-03h  1
>   195  2.5373612e+04 2.40e+04 6.11e+23   1.9 2.05e+05  19.2 1.00e+00
> 6.26e-04h  1
>   196  2.5373315e+04 2.40e+04 6.11e+23   1.7 2.39e+04  19.6 1.00e+00
> 3.24e-05h  1
> WARNING: Problem in step computation; switching to emergency mode.
>   197r 2.5373315e+04 2.40e+04 1.00e+03   4.4 0.00e+00  19.1 0.00e+00
> 0.00e+00R  1
>
> There was a release 3.11.10 which mentioned a memory allocation bug, but
> this does not seem to me like that.
> Both crashes seem to have something to do with smart pointers (see the
> attached error logs for stack trace) and curiously both have the same
> function (Journalist#printf,
> _ZNK5Ipopt10Journalist6PrintfENS_13EJournalLevelENS_16EJournalCategoryEPKcz)
> in callee-saved register.
>
> I would've reported this error in trac, but I seem to get this error on
> every form submission there: Missing or invalid form token. Do you have
> cookies enabled?
>
> Do the stack traces point enough to correct direction, or would more
> information be useful? I don't see an easy way to make this easily
> reproduceable.
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>