[Osi] Two issues in OsiCpxSolverInterface

Christian Troost christian.troost at uni-hohenheim.de
Wed Feb 17 08:03:05 EST 2016


Dear Stefan, dear Ted,

thanks for your help.
Yes, problem 1 is solved in the new stable/0.107.

Problem 2 persists, but my diagnostics was wrong as pointed out by
Stefan. (I had overlooked the line  handler_ = new CoinMessageHandler();
I was confused by handler_(NULL) in the initializer list.)

So, here is a better description of my problem:

If I use a fresh OsiCpxSolverInterface (i.e. using the default message
handler), load a MIP model and solve it,
there is no problem.
a) If I then reset the interface, load a new model and solve it,
valgrind reports the following:

Invalid read of size 4
==4996== at 0x4E429AC: OsiCpxMessageCallbackResultLog(void*, char
const*) (OsiCpxSolverInterface.cpp:127)
==4996== by 0x5737705: CPXmsg (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x59123F2: _27238022f5e3f175ca5f7edb796e9947 (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x5894D37: _c922267c5e01d00bf561d516e9fee851 (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x58B0C6C: _215fb8005dc0640fae830b5cbad3d4e5 (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x586C292: CPXmipopt (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x58987E2: _76182aa5c271d2b9d42ecbb5b0b2c037 (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x58A8BFA: _ec79392c4d1d473738a84868649054a8 (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x58AA005: _e5712b9003b642b23727cfade14cabcd (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x58988C9: _e55849dd2cc2c00e07ff7d7e4f431460 (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x586C336: CPXmipopt (in
/home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)
==4996== by 0x4E4B5BE: OsiCpxSolverInterface::branchAndBound()
(OsiCpxSolverInterface.cpp:532)
==4996== Address 0x6faeaa8 is 104 bytes inside a block of size 1,600 free'd
==4996== at 0x4C2C2BC: operator delete(void*) (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4996== by 0x5097EB3: OsiSolverInterface::setInitialData()
(OsiSolverInterface.cpp:1012)
==4996== by 0x4E4FFA0: OsiCpxSolverInterface::reset(
(OsiCpxSolverInterface.cpp:3500)

This does not immediately crash the program, but after a few repetitions
of resetting, loading and solving it does.

b) If I alternatively pass in my own messageHandler (Allocating my
messageHandler once before the first LP is solved and deallocate it
after the last LP has been solved) using passInMessageHandler() after
every reset,  OsiCpxSolverInterface throws an exception in
passInMessageHandler:
"CPXdelfuncdest returned error 1053"

As a workaround I am now just catching that exception and proceed normally.

My second guess at what is going wrong is that in reset() CPXdelfuncdest
should be called before the old handler is set to NULL (and the default
handler is deleted )
and then CPXaddfuncdest should be called with the newly allocated handler.

Otherwise,
in a) CPLEX's internal memory still points to a deallocated handler, or
in b) the memory is still there, because it is allocated in the main,
but the default message handler allocated by reset was never known to
CPLEX and thus cannot be deleted with CPXdelfuncdest.

Hope my diagnostics is better this time ;)

Best,
Christian






On 17/02/16 04:06, Ted Ralphs wrote:
> Hi Christian,
> 
> Looks like Stefan fixed at least one of these issues in trunk and 
> stable. Can you take a look?
> 
> Cheers,
> 
> Ted
> 
> On Fri, Feb 12, 2016 at 10:39 AM, Christian Troost 
> <christian.troost at uni-hohenheim.de 
> <mailto:christian.troost at uni-hohenheim.de>> wrote:
> 
> Dear OsiCpx-Team,
> 
> I am currently testing the OsiCpxSolverInterface for our
> application.
> 
> I stumbled over two issues that are probably bugs in the code:
> 
> 1) In OsiCpxSolverInterface::getRowActivity() the rowact_ array is
> never populated and remains unititialized if if( probtypemip_ ) AND
> #if CPX_VERSION >= 1100 AND  if( solntype != CPX_NO_SOLN )
> 
> 2) In OsiCpxSolverInterface::reset():
> 
> OsiCpxSolverInterface calls parent
> OsiSolverInterface::setInitialData(),
> 
> which does the following to the message handler:
> 
> if (defaultHandler_) { delete handler_; handler_ = NULL; } 
> defaultHandler_=true;
> 
> Now, what if a user passes in a message handler? According to the
> headers it is the users' responsibility to deallocate the message
> handler. So, assume the following sequence:
> 
> A user allocates a message handler in his application The user passes
> in this message handler (this will set defaultHandler_= false) to
> OsiCpxSolverInterface. After some time, the user calls ->reset and
> deallocates the message handler in his application
> 
> Since defaultHandler_ was false, handler_ has not been set to NULL
> in reset, but rather still points to the now deallocated memory.
> 
> If the user now reuses the SolverInterface for the next problem,
> without passing in a messageHandler object the program may segfault
> on the first use of the message handler
> 
> May not happen to often, but I had a problem and this seemed to be
> the reason ...
> 
> 
> Best, Christian _______________________________________________ Osi
> mailing list Osi at list.coin-or.org <mailto:Osi at list.coin-or.org> 
> http://list.coin-or.org/mailman/listinfo/osi
> 
> 
> 
> 
> -- Dr. Ted Ralphs Professor, Lehigh University (610) 628-1280 ted
> 'at' lehigh 'dot' edu coral.ie.lehigh.edu/~ted
> <http://coral.ie.lehigh.edu/~ted>


More information about the Osi mailing list