[Ipopt] More Mac Mex File Crashes

Tony Kelman kelman at berkeley.edu
Mon Mar 9 20:13:42 EDT 2015

I don't think it's going to be fixed unless someone who uses the combination 
of OSX, Matlab, and Ipopt finds and proposes a fix. I'll gladly review any 
patches to address this if someone can come up with something to try 
changing in the code.

There are interfaces to Ipopt from all of Python, R, and Julia. As I 
understand it, the Python and R interfaces require compiling some mex-like 
glue code. The Julia interface does not, all you need is a compiled 
ipopt.dylib (or dll or so) and the Julia wrappers work through the existing 
C interface, no compiled glue code required. I do not believe there are 
precompiled binaries posted anywhere for the Python or R wrappers, but I 
could be wrong. The Julia package Ipopt.jl is set up in such a way that, on 
OSX or Windows, it automatically downloads a compiled Ipopt binary when you 
install it via Pkg.add("Ipopt"). On Linux it needs to compile Ipopt from 
source, or you can point it to an existing libipopt.so if you already have 
one available.

Redistributing binaries of MA57 is not allowed by the HSL license without 
paying an additional license fee. The Matlab interface to Ipopt is able to 
use the binary version of MA57 that Matlab itself distributed (and uses for 
the sparse "ldl" function), but this may be at least partially the cause of 
the instability you're hitting on OSX. If you ask for linear_solver mumps, 
does the Matlab interface still crash?

The Python, R, and Julia interfaces to Ipopt are not going to be able to 
distribute precompiled MA57 binaries for licensing reasons (without some 
organization paying the fee that Mathworks did). They can however use the 
linear solver loader functionality in Ipopt. You can compile a binary of 
Ipopt using just Mumps, but if you select linear_solver ma57 and you put a 
libhsl.dylib (or dll or so) file somewhere on the path or next to libipopt, 
it can dynamically load and use it.

With some additional work, it might also be possible to install the 
redistributable Matlab Compiler Runtime which should also include a binary 
of ma57, and try using that in Ipopt via the linear solver loader from one 
of these other languages. As far as I'm aware this has not yet been tried.


-----Original Message----- 
From: Anil Rao
Sent: Monday, March 09, 2015 4:54 PM
To: ipopt at list.coin-or.org
Subject: [Ipopt] More Mac Mex File Crashes


I have reported this problem before, but I am reporting it again because it 
seems as if it has not been fixed.  I continually get crashes when I run the 
Mac OS-X versions of the precompiled IPOPT mex files.  I do not know why the 
crash occurs, but it happens frequently and it seems as if it is specific to 
the Mac.  An example of the crash is shown the following crash dump file.

To be honest, I have no idea why such a problem exists on a Mac (which is 
UNIX, so I would expect better reliability).  This problem does not seem to 
occur on a Windows machine (makes me want to switch to Windows, perish the 
thought!).  Anyway, any help is greatly appreciated.

On a separate note, are there IPOPT mex files (or equivalent) for languages 
such as Python, R, or Julia?  If so, has anyone uploaded precompiled 
versions of such executables for these other languages?  Finally, would any 
such mex files have MA57 capability, or would they be limited to just being 
able to use Mumps?

Thanks in advance for any help anyone can provide.

Anil Rao

              abort() detected at Mon Mar  9 19:45:44 2015

  Crash Decoding      : Disabled
  Crash Mode          : continue (default)
  Current Graphics Driver: Unknown hardware
  Current Visual      : Quartz
  Default Encoding    : ISO-8859-1
  Host Name           : Anils-MacBook-Pro.local
  MATLAB Architecture : maci64
  MATLAB Root         : /Applications/MATLAB_R2015a.app
  MATLAB Version      : (R2015a)
  OpenGL              : hardware
  Operating System    : Darwin 14.1.0 Darwin Kernel Version 14.1.0: Mon Dec 
22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 x86_64
  Processor ID        : x86 Family 6 Model 58 Stepping 9, GenuineIntel
  Virtual Machine     : Java 1.7.0_60-b19 with Oracle Corporation Java 
HotSpot(TM) 64-Bit Server VM mixed mode
  Window System       : Quartz

Fault Count: 1

Abnormal termination:

Register State (from fault):
  RAX = 000000011c373af8  RBX = 0000000000000000
  RCX = 0000000000000003  RDX = 000000011c37209c
  RSP = 0000000000000016  RBP = 00007fff8d7f09a7
  RSI = 000000011c372080  RDI = 000000011c380000

   R8 = 0000000000000006   R9 = 00000001513467a5
  R10 = 000000011c372660  R11 = 000000011c380000
  R12 = 00007f9497aa2600  R13 = 000000011c3720b0
  R14 = 00007fff8d7f142f  R15 = 0000000000000000

  RIP = 00004d031c3720d0  RFL = 000000011c3720d0

   CS = 000000011c3722b0   FS = 000000011c3720e0   GS = 00007fff9c0c4b53

Stack Trace (from fault):
[  0] 0x000000011044e964 
[  1] 0x000000011045202b 
[  2] 0x0000000110451ac7 
[  3] 0x000000010ff74f9b 
[  4] 0x000000010ff75217 
[  5] 0x000000010ff74908 
[  6] 0x000000010ff742cc 
[  7] 0x00007fff9385ef1a 
/usr/lib/system/libsystem_platform.dylib+00020250 _sigtramp+00000026
[  8] 0x0000000000000000 
[  9] 0x00007fff9c0c4b53 
/usr/lib/system/libsystem_c.dylib+00383827 abort+00000129
[ 10] 0x0000000151397fb6 

This error was detected while a MEX-file was running. If the MEX-file
is not an official MathWorks function, please examine its source code
for errors. Please consult the External Interfaces Guide for information
on debugging MEX-files.

If this problem is reproducible, please submit a Service Request via:

A technical support engineer might contact you with further information.

Thank you for your help.

Anil V. Rao, PhD
Associate Professor
Department of Mechanical and Aerospace Engineering
University of Florida
Gainesville, FL 32611-6250
Tel:  (352) 672-1529
E-mail:  anilvrao at gmail.com

Ipopt mailing list
Ipopt at list.coin-or.org

More information about the Ipopt mailing list