[Osi] Two issues in OsiCpxSolverInterface

[Ted Ralphs]

FYI, I just made a new release of Osi including these fixes.

Ted

On Wed, Feb 17, 2016 at 10:12 AM, Christian Troost <
christian.troost at uni-hohenheim.de> wrote:

> Dear Stefan,
>
> yes, problem solved now. Valgrind reports no errors in version a) and no
> exception thrown in version b).
>
> Thanks a lot,
>
> Christian
>
>
> On 17/02/16 15:27, Stefan Vigerske wrote:
> > Hi,
> >
> > I think your second guess is correct.
> > I implemented this and commited it to trunk. Can you try out whether
> > this solves the issue?
> >
> > Thanks,
> > Stefan
> >
> > On 02/17/2016 02:03 PM, Christian Troost wrote:
> >> 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>
> >>
> >
> >
>



-- 
Dr. Ted Ralphs
Professor, Lehigh University
(610) 628-1280
ted 'at' lehigh 'dot' edu
coral.ie.lehigh.edu/~ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/osi/attachments/20160222/36183886/attachment.html>