<div dir="ltr">FYI, I just made a new release of Osi including these fixes. <div><br></div><div>Ted</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 17, 2016 at 10:12 AM, Christian Troost <span dir="ltr"><<a href="mailto:christian.troost@uni-hohenheim.de" target="_blank">christian.troost@uni-hohenheim.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Stefan,<br>
<br>
yes, problem solved now. Valgrind reports no errors in version a) and no<br>
exception thrown in version b).<br>
<br>
Thanks a lot,<br>
<br>
Christian<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 17/02/16 15:27, Stefan Vigerske wrote:<br>
> Hi,<br>
><br>
> I think your second guess is correct.<br>
> I implemented this and commited it to trunk. Can you try out whether<br>
> this solves the issue?<br>
><br>
> Thanks,<br>
> Stefan<br>
><br>
> On 02/17/2016 02:03 PM, Christian Troost wrote:<br>
>> Dear Stefan, dear Ted,<br>
>><br>
>> thanks for your help.<br>
>> Yes, problem 1 is solved in the new stable/0.107.<br>
>><br>
>> Problem 2 persists, but my diagnostics was wrong as pointed out by<br>
>> Stefan. (I had overlooked the line  handler_ = new CoinMessageHandler();<br>
>> I was confused by handler_(NULL) in the initializer list.)<br>
>><br>
>> So, here is a better description of my problem:<br>
>><br>
>> If I use a fresh OsiCpxSolverInterface (i.e. using the default message<br>
>> handler), load a MIP model and solve it,<br>
>> there is no problem.<br>
>> a) If I then reset the interface, load a new model and solve it,<br>
>> valgrind reports the following:<br>
>><br>
>> Invalid read of size 4<br>
>> ==4996== at 0x4E429AC: OsiCpxMessageCallbackResultLog(void*, char<br>
>> const*) (OsiCpxSolverInterface.cpp:127)<br>
>> ==4996== by 0x5737705: CPXmsg (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x59123F2: _27238022f5e3f175ca5f7edb796e9947 (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x5894D37: _c922267c5e01d00bf561d516e9fee851 (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x58B0C6C: _215fb8005dc0640fae830b5cbad3d4e5 (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x586C292: CPXmipopt (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x58987E2: _76182aa5c271d2b9d42ecbb5b0b2c037 (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x58A8BFA: _ec79392c4d1d473738a84868649054a8 (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x58AA005: _e5712b9003b642b23727cfade14cabcd (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x58988C9: _e55849dd2cc2c00e07ff7d7e4f431460 (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x586C336: CPXmipopt (in<br>
>> /home/troost/ILOG/CPLEX_Studio122/cplex/bin/x86-64_sles10_4.1/libcplex122.so)<br>
>><br>
>> ==4996== by 0x4E4B5BE: OsiCpxSolverInterface::branchAndBound()<br>
>> (OsiCpxSolverInterface.cpp:532)<br>
>> ==4996== Address 0x6faeaa8 is 104 bytes inside a block of size 1,600<br>
>> free'd<br>
>> ==4996== at 0x4C2C2BC: operator delete(void*) (in<br>
>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)<br>
>> ==4996== by 0x5097EB3: OsiSolverInterface::setInitialData()<br>
>> (OsiSolverInterface.cpp:1012)<br>
>> ==4996== by 0x4E4FFA0: OsiCpxSolverInterface::reset(<br>
>> (OsiCpxSolverInterface.cpp:3500)<br>
>><br>
>> This does not immediately crash the program, but after a few repetitions<br>
>> of resetting, loading and solving it does.<br>
>><br>
>> b) If I alternatively pass in my own messageHandler (Allocating my<br>
>> messageHandler once before the first LP is solved and deallocate it<br>
>> after the last LP has been solved) using passInMessageHandler() after<br>
>> every reset,  OsiCpxSolverInterface throws an exception in<br>
>> passInMessageHandler:<br>
>> "CPXdelfuncdest returned error 1053"<br>
>><br>
>> As a workaround I am now just catching that exception and proceed<br>
>> normally.<br>
>><br>
>> My second guess at what is going wrong is that in reset() CPXdelfuncdest<br>
>> should be called before the old handler is set to NULL (and the default<br>
>> handler is deleted )<br>
>> and then CPXaddfuncdest should be called with the newly allocated<br>
>> handler.<br>
>><br>
>> Otherwise,<br>
>> in a) CPLEX's internal memory still points to a deallocated handler, or<br>
>> in b) the memory is still there, because it is allocated in the main,<br>
>> but the default message handler allocated by reset was never known to<br>
>> CPLEX and thus cannot be deleted with CPXdelfuncdest.<br>
>><br>
>> Hope my diagnostics is better this time ;)<br>
>><br>
>> Best,<br>
>> Christian<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 17/02/16 04:06, Ted Ralphs wrote:<br>
>>> Hi Christian,<br>
>>><br>
>>> Looks like Stefan fixed at least one of these issues in trunk and<br>
>>> stable. Can you take a look?<br>
>>><br>
>>> Cheers,<br>
>>><br>
>>> Ted<br>
>>><br>
>>> On Fri, Feb 12, 2016 at 10:39 AM, Christian Troost<br>
>>> <<a href="mailto:christian.troost@uni-hohenheim.de">christian.troost@uni-hohenheim.de</a><br>
>>> <mailto:<a href="mailto:christian.troost@uni-hohenheim.de">christian.troost@uni-hohenheim.de</a>>> wrote:<br>
>>><br>
>>> Dear OsiCpx-Team,<br>
>>><br>
>>> I am currently testing the OsiCpxSolverInterface for our<br>
>>> application.<br>
>>><br>
>>> I stumbled over two issues that are probably bugs in the code:<br>
>>><br>
>>> 1) In OsiCpxSolverInterface::getRowActivity() the rowact_ array is<br>
>>> never populated and remains unititialized if if( probtypemip_ ) AND<br>
>>> #if CPX_VERSION >= 1100 AND  if( solntype != CPX_NO_SOLN )<br>
>>><br>
>>> 2) In OsiCpxSolverInterface::reset():<br>
>>><br>
>>> OsiCpxSolverInterface calls parent<br>
>>> OsiSolverInterface::setInitialData(),<br>
>>><br>
>>> which does the following to the message handler:<br>
>>><br>
>>> if (defaultHandler_) { delete handler_; handler_ = NULL; }<br>
>>> defaultHandler_=true;<br>
>>><br>
>>> Now, what if a user passes in a message handler? According to the<br>
>>> headers it is the users' responsibility to deallocate the message<br>
>>> handler. So, assume the following sequence:<br>
>>><br>
>>> A user allocates a message handler in his application The user passes<br>
>>> in this message handler (this will set defaultHandler_= false) to<br>
>>> OsiCpxSolverInterface. After some time, the user calls ->reset and<br>
>>> deallocates the message handler in his application<br>
>>><br>
>>> Since defaultHandler_ was false, handler_ has not been set to NULL<br>
>>> in reset, but rather still points to the now deallocated memory.<br>
>>><br>
>>> If the user now reuses the SolverInterface for the next problem,<br>
>>> without passing in a messageHandler object the program may segfault<br>
>>> on the first use of the message handler<br>
>>><br>
>>> May not happen to often, but I had a problem and this seemed to be<br>
>>> the reason ...<br>
>>><br>
>>><br>
>>> Best, Christian _______________________________________________ Osi<br>
>>> mailing list <a href="mailto:Osi@list.coin-or.org">Osi@list.coin-or.org</a> <mailto:<a href="mailto:Osi@list.coin-or.org">Osi@list.coin-or.org</a>><br>
>>> <a href="http://list.coin-or.org/mailman/listinfo/osi" rel="noreferrer" target="_blank">http://list.coin-or.org/mailman/listinfo/osi</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> -- Dr. Ted Ralphs Professor, Lehigh University <a href="tel:%28610%29%20628-1280" value="+16106281280">(610) 628-1280</a> ted<br>
>>> 'at' lehigh 'dot' edu <a href="http://coral.ie.lehigh.edu/~ted" rel="noreferrer" target="_blank">coral.ie.lehigh.edu/~ted</a><br>
>>> <<a href="http://coral.ie.lehigh.edu/~ted" rel="noreferrer" target="_blank">http://coral.ie.lehigh.edu/~ted</a>><br>
>><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Dr. Ted Ralphs<br>Professor, Lehigh University<br>(610) 628-1280<br>ted 'at' lehigh 'dot' edu<br><a href="http://coral.ie.lehigh.edu/~ted" target="_blank">coral.ie.lehigh.edu/~ted</a><br></div></div>
</div>