[Osi] Two issues in OsiCpxSolverInterface

[Stefan Vigerske]

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>
>


-- 
http://www.gams.com/~stefan