[Ipopt] IPOPT build causes crash inside MATLAB

[Joel Andersson]

Thanks a lot for your help!

I think you are completely right about the cause of the problem, but I
found another solution that also appears to work. I had CasADi load the
IPOPT plugin with RTLD_LAZY | RTLD_LOCAL | RTLD_DEEPBIND passed to dlopen.
That way, IPOPT's BLAS won't interfere with MATLAB's BLAS (MATLAB won't see
it thanks to RTLD_LOCAL) and MATLAB's BLAS won't interfere with IPOPT's
BLAS (RTLD_DEEPBIND will ensure that IPOPT's BLAS has priority).

Not sure if there are any disadvantages of this approach.

Best regards,
Joel




2015-01-14 13:00 GMT+01:00 Tony Kelman <kelman at berkeley.edu>:

>   Matlab’s own copy of BLAS uses 64-bit integers. Ipopt and most other
> libraries expect conventional 32-bit integers in BLAS. You need to link
> Ipopt to a static-library BLAS to avoid this problem, otherwise there are
> two shared-library copies of BLAS opened by the same process using the same
> function names but binary-incompatible signatures and bad things happen.
> You can alternately tell Matlab to use the same copy of BLAS that you built
> with Ipopt by setting BLAS_VERSION environment variables, but this is not
> well-supported and could easily slow unrelated linear algebra down if
> you’re not using an optimized implementation.
>
> -Tony
>
>
>  *From:* Joel Andersson <j.a.e.andersson at gmail.com>
> *Sent:* Wednesday, January 14, 2015 3:40 AM
> *To:* Ipopt - Mailing list <ipopt at list.coin-or.org>
> *Subject:* [Ipopt] IPOPT build causes crash inside MATLAB
>
>  Hello all,
>
> I am working on adding a MATLAB front-end to CasADi that will enable
> formulating and solving large-scale NLPs with efficient automatic
> calculation of Jacobians and Hessians.
>
> I am experiencing problems of getting our IPOPT plugin to work inside
> MATLAB. While it appears to work fine in OS X, I get segfaults in Linux
> (Ubuntu 14.04, 64-bit, gcc 4.7) with the following stack trace:
>
>  Stack Trace (from fault):
> [  0] 0x00007f607282eb0c
> /usr/local/MATLAB/R2014b/bin/glnxa64/mkl.so+31877900
> mkl_blas_cnr_def_xdcopy+00000252
> [  1] 0x00007f6070ca3778
> /usr/local/MATLAB/R2014b/bin/glnxa64/mkl.so+02996088 mkl_blas_dcopy+00000200
> [  2] 0x00007f6070b1381c
> /usr/local/MATLAB/R2014b/bin/glnxa64/mkl.so+01357852 dcopy+00000080
> [  3] 0x00007f6074f76565
> /usr/local/lib/libipopt.so.0+01639781
> _ZN5Ipopt11IpBlasDcopyEiPKdiPdi+00000085
> [  4] 0x00007f6074e65762
> /usr/local/lib/libipopt.so.0+00522082
> _ZN5Ipopt11TNLPAdapter16GetStartingPointENS_8SmartPtrINS_6VectorEEEbS3_bS3_bS3_bS3_b+00001106
> [  5] 0x00007f6074ebdc78
> /usr/local/lib/libipopt.so.0+00883832
> _ZN5Ipopt15GradientScaling30DetermineScalingParametersImplENS_8SmartPtrIKNS_11VectorSpaceEEES4_S4_NS1_IKNS_11MatrixSpaceEEES7_NS1_IKNS_14SymMatrixSpaceEEERKNS_6MatrixERKNS_6VectorESD_SG_RdRNS1_ISE_EESJ_SJ_+00000232
> ...
>
> Anyone has any idea of what could be the cause of this or how it can be
> resolved? It appears to be related to BLAS which I find perplexing since
> IPOPT is not linked to the MEX function, but to a plugin (shared library)
> which is loaded dynamically using dlopen(..., RTLD_LAZY | RTLD_LOCAL). I
> thought that would provide enough encapsulation to avoid problems like this.
>
> I tried building IPOPT explicitly avoid MKL blas by setting
> "--with-build=BUILD --with-lapack=BUILD":
>
> ../configure --prefix=/usr/local --with-build=BUILD --with-lapack=BUILD
> ADD_FFLAGS=-fPIC ADD_CFLAGS=-fPIC ADD_CXXFLAGS=-fPIC
>
> But that doesn't appear to have any effect.
>
> Best regards and thanks in advance,
> Joel
>
>
>
> ------------------------------
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>
>


-- 
-- 
Joel Andersson, PhD
Ptge. Busquets 11-13, atico 3
E-08940 Cornella de Llobregat, Spain
Home: +34-93-6034011
Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) / +46-707-360512
(Sweden)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20150114/6a90378f/attachment-0001.html>