[Ipopt] Matlab interface crashes for limited memory Hessian

[Tom Vacek]

Follow-up:

The problem is caused by an API difference between mwblas/mwlapack and 
the prototypes in IpBlas.cpp/IpLapackcpp.  mwblas/mwlapack uses an 
8-byte integral type whereas ipfint is typedef-ed as int, which is 4 
bytes on my system (Ubuntu x86_64).  Given the backtrace I reported 
below, the problem is obvious.

I suspect that the behavior reported in the backtrace is caused by a 
name space collision.  The symbols in my libgoto2 are the same as those 
in mwblas, and the collision occurs when both libraries are loaded.  I 
have no idea why the problem seems to arise only when the limited memory 
Hessian option is invoked.

I hacked a solution by modifying the IpBlas.cpp and IpLapack.cpp files 
to reflect the matlab API.  I also had to write FORTRAN wrappers for 
blas calls in ma57.  Then I linked everything to mwblas/mwlapack.  
Everything works!  In hindsight, it might have been easier to redefine 
the ipfint, Index, and Int types to int64_t.

Finally, I think it would be good practice to encourage users to supply 
cblas and clapack headers, so that they would get a compiler error if 
the API did not match the assumed one.

Thanks,

Tom



On 03/11/2011 06:26 PM, Thomas Vacek wrote:
> This is a follow up on the Matlab interface problem when using the
> Hessian approximation.  In short, my mex file has no dependency on mwlapack:
>
> % ldd ipopt.mexa64
>      linux-vdso.so.1 =>   (0x00007fff1ddff000)
>      libipopt.so.1 =>
> /home/it02/vacek008/Linux-x86_64/lib/coin/libipopt.so.1 (0x00007f1757d32000)
>      libdl.so.2 =>  /lib/libdl.so.2 (0x00007f1757b07000)
>      libcoinhsl.so.1 =>
> /home/it02/vacek008/Linux-x86_64/lib/coin/ThirdParty/libcoinhsl.so.1
> (0x00007f17578d7000)
>      libgoto2.so =>  /home/it02/vacek008/Linux-x86_64/lib/libgoto2.so
> (0x00007f1756c07000)
>      libmetis.so.1 =>  /home/it02/vacek008/Linux-x86_64/lib/libmetis.so.1
> (0x00007f17569bf000)
>      libgfortran.so.3 =>  /soft/gcc-4.3/ubuntuamd1/lib64/libgfortran.so.3
> (0x00007f17567e5000)
>      libgcc_s.so.1 =>  /soft/gcc-4.3/ubuntuamd1/lib64/libgcc_s.so.1
> (0x00007f17566ce000)
>      libmx.so =>  not found
>      libmex.so =>  not found
>      libmat.so =>  not found
>      libm.so.6 =>  /lib/libm.so.6 (0x00007f1756449000)
>      libstdc++.so.6 =>  /soft/gcc-4.3/ubuntuamd1/lib64/libstdc++.so.6
> (0x00007f1756244000)
>      libpthread.so.0 =>  /lib/libpthread.so.0 (0x00007f1756027000)
>      libc.so.6 =>  /lib/libc.so.6 (0x00007f1755ca3000)
>      /lib64/ld-linux-x86-64.so.2 (0x00007f17584c0000)
>
> But yet a backtrace in GDB shows that the Lapack library being used is
> actually mwlapack:
>
> #0  0x00007fffeb99ed6d in dpotrf_ ()
>     from
> /soft/matlab2010b/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libmwlapack.so
> #1  0x00007fffd92f0506 in Ipopt::IpLapackDpotrf (ndim=1, a=0x3e7aa90,
> lda=1, info=@0x7fffe8781ed0) at IpLapack.cpp:76
> #2  0x00007fffd92e5341 in Ipopt::DenseGenMatrix::ComputeCholeskyFactor
> (this=0x3e7aa20, M=...) at IpDenseGenMatrix.cpp:156
> ...
>
> I assume that the C wrappers are different, and hence the problem.  Does
> anyone have other ideas?  How can I make Matlab use the Blas library
> that the code is really linked to?  I'll ask about this on the Matlab
> forum, too.
>
> Thanks!
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt