[Osi] Two issues in OsiCpxSolverInterface

[Christian Troost]

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