[Coin-discuss] Problems with ipopt on OS X

[Geoff Leyland]

On 16/12/2010, at 6:43 PM, Geoff Leyland wrote:

> Or maybe now I can use Kipp's precompiled ipopt lib successfully - I'll try that too.

Sorry to reply to myself, but this (almost) worked.  Relevant line from the makefile is

rima_ipopt_core.$(SO_SUFFIX): c/rima_ipopt_core.cpp
	$(CPP) $(CFLAGS) $(SHARED) $^ -o $@ -L$(IPOPT_LIBDIR) -lipopt -lgfortran -framework vecLib $(LIBS) -I$(LUA_INCDIR) -I$(IPOPT_INCDIR)

where the -lgfortran is from http://hpc.sourceforge.net/.

So, it works.  You formulate the problem symbolically, rima handles the numeric differentiation, and luajit compiles the objective function, constraints, jacobians and hessians to assembler (Actually, I might be getting a bit ahead of myself here, I haven't done much testing, but it will do that shortly).

Just before everything finishes, there's another free of an unallocated block.  Valgrind (Memcheck) says:

==46941== Invalid free() / delete / delete[]
==46941==    at 0x10003DE0C: operator delete(void*) (vg_replace_malloc.c:387)
==46941==    by 0x101336FC5: Ipopt::TNLPAdapter::~TNLPAdapter() (in /Users/geoff/projects/rima/trunk-google/lua/rima_ipopt_core.so)
==46941==  Address 0x101278da8 is 40 bytes inside a block of size 88 alloc'd
==46941==    at 0x10003E7AF: malloc (vg_replace_malloc.c:236)
==46941==    by 0x10003EA31: realloc (vg_replace_malloc.c:525)
==46941==    by 0x10000B30F: luaM_realloc_ (in /opt/local/bin/lua)
==46941==    by 0x10000ED67: luaS_newudata (in /opt/local/bin/lua)
==46941==    by 0x100002BC5: lua_newuserdata (in /opt/local/bin/lua)
==46941==    by 0x101321C93: rima_new(lua_State*) (rima_ipopt_core.cpp:486)
==46941==    by 0x1000079D1: luaD_precall (in /opt/local/bin/lua)
==46941==    by 0x1000125C4: luaV_execute (in /opt/local/bin/lua)
==46941==    by 0x100007E6C: luaD_call (in /opt/local/bin/lua)
==46941==    by 0x100007516: luaD_rawrunprotected (in /opt/local/bin/lua)
==46941==    by 0x10000758F: luaD_pcall (in /opt/local/bin/lua)
==46941==    by 0x100002FB6: lua_pcall (in /opt/local/bin/lua)

Unfortunately, because I'm using Kipp's ipopt, I don't have any symbols in ~TNLPAdapter.  When an Ipopt::IpoptApplication's destructor runs, it destroys a TNLP adapter, and one of the things it deletes was not on the heap in the first place.  I've checked this by arranging for the IpoptApplication to leak.

The address freed is the address of the rima_ipopt_model (a subclass of TNLP).  I can't see anything in ~TNLPAdapter that looks like it's trying to delete the model.  Oh, it's probably the smart pointer in Ipopt::IpoptApplication to the NLP trying to delete the model.  Reference counting meets the Lua GC!  Is there any way I can tell the RC to leave it alone?  (ie, a cheap way to bump the reference count?)

Cheers,
Geoff