<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
Hi John,<br>
<br>
I read the documentation of "preProcessNonDefault" (where it says
"returns the new problem") and jumped to conclusions, which seem (in
retrospect) to not have been justified. Should have checked with
valgrind before posting to this list.<br>
<br>
Anyway, just out of curiosity: it is still not clear to me, who is
responsible for freeing the OsiSolverInterface instance returned by
"CglPreProcess::preProcessNonDefault". It's copy ("solver3" in my
original code) will be taken care of by "CbcModel::assignModel", but
the result of "preProcessNonDefault" ("solver2") looks like it is
leaked (though it isn't as the valgrind log shows).<br>
<br>
Regardless, thanks for the answer and sorry for the noise.<br>
<br>
Cheers,<br>
Dirk<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 09.05.2014 15:58, schrieb John
Forrest:<br>
</div>
<blockquote cite="mid:536CDF23.3060005@fastercoin.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Dirk,<br>
<br>
Not exactly sure where the problem was - I rearranged code a bit
and it seems OK and without a leak. See if it fixes.<br>
<br>
John Forrest<br>
On 09/05/14 11:00, Dirk Eßer wrote:<br>
</div>
<blockquote cite="mid:536CA726.5030104@web.de" type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
Hi John,<br>
<br>
thanks for the reply. I now have a minimal example (for some
definition of minimal, which you can find attached), with which
I can reproduce the access violation. Right now, it seems, that
I have the choice between<br>
<ul>
<li>getting a segfault when trying to clean-up all solvers
instanciated during the program run, or</li>
<li>leaking a solver instance.</li>
</ul>
<p>I am not quite comfortable with option 2, since I don't know,
how much memory is actually leaked in this case, in particular
as the actual application will solve quite a few MIPs
sequentially in the same process. If it were only a couple of
bytes per solver instance, then I am almost willing accept
that as "price to pay" for the preprocessing step. But I don't
know the inner workings of the solvers involved enough to make
a judgement here.<br>
</p>
<p>Also, I am still not convinced, that the error isn't entirely
in our own code; right now, though, I don't see anything
inherently wrong. Any help appreciated.<br>
</p>
<p><br>
Cheers,<br>
Dirk Eßer<br>
</p>
<br>
<br>
<div class="moz-cite-prefix">Am 07.05.2014 19:36, schrieb John
Forrest:<br>
</div>
<blockquote cite="mid:536A6F1F.60508@fastercoin.com" type="cite">
<div class="moz-cite-prefix">Dirk,<br>
<br>
The -cpp was a nice idea - but impossible to keep current -
so something may be broken.<br>
<br>
Try using code from the Cbc/examples driver3.cpp or
driver4.cpp which should give you the same flexibility.<br>
<br>
John Forrest<br>
On 07/05/14 11:18, Dirk Eßer wrote:<br>
</div>
<blockquote cite="mid:536A0873.8030802@web.de" type="cite">
Hello,<br>
<br>
I have a little problem adding a preprocessing step to
program doing MIP solving using the CBC library. The problem
is, that the program fails with more or less random memory
corruption (and in the better cases: with a segfault) some
of the time.<br>
<br>
The CbcModel instance is created programmatically<br>
<blockquote><small>OsiClpSolverInterface iface;<br>
CoinPackedMatrix pmx(false, num_columns, num_rows,
num_elements, matrix, columns, starts, lengths);<br>
<br>
iface.setObjSense(-1.0);<br>
iface.loadProblem(pmx, 0, 0, objective, senses, rights,
0);<br>
iface.passInMessageHandler(&printer);<br>
<br>
model_ptr LP(new CbcModel(iface));<br>
... adding stuff via LP->addObjects(...) to declare
integer constraints on variables and a few SOSes ...</small><br>
</blockquote>
Things work fine, if we directly compute a solution without
further preprocessing via<br>
<blockquote><small>LP->initialSolve();<br>
LP->branchAndBound();</small><br>
</blockquote>
We now try to add a pre-processing step to the solution
process. As a starting point, we used the driver code
generated by the CBC command line tool ("-cpp 0", which
doesn't compile). <br>
<blockquote><small>OsiSolverInterface* original_solver =
LP->solver();<br>
OsiSolverInterface* cloned_solver =
original_solver->clone();<br>
OsiSolverInterface* configured_solver = 0;<br>
<br>
cloned_solver->passInMessageHandler(LP->messageHandler());<br>
cloned_solver->setHintParam(OsiDoInBranchAndCut,
true, OsiHintDo);<br>
<br>
CglPreProcess processor;<br>
<br>
{<br>
CglProbing prober;<br>
prober.setUsingObjective(1);<br>
prober.setMaxPass(3);<br>
prober.setMaxProbeRoot(cloned_solver->getNumCols());<br>
prober.setMaxElements(100);<br>
prober.setMaxLookRoot(50);<br>
prober.setRowCuts(3);<br>
processor.addCutGenerator(&prober);<br>
}<br>
<br>
configured_solver =
processor.preProcessNonDefault(*cloned_solver, 2, 10); <br>
<br>
cloned_solver->setHintParam(OsiDoInBranchAndCut,
false, OsiHintDo);<br>
<br>
if (!configured_solver)<br>
{<br>
delete cloned_solver;<br>
return status::infeasible;<br>
}<br>
<br>
configured_solver->setHintParam(OsiDoInBranchAndCut,
false, OsiHintDo);<br>
<br>
OsiSolverInterface* configured_clone =
configured_solver->clone();<br>
<br>
LP->assignSolver(configured_clone, true /* Kill
previous solver */); /*-- XXX --*/<br>
LP->initialSolve();<br>
LP->branchAndBound();<br>
<br>
int n_cols = cloned_solver->getNumCols();<br>
processor.postProcess(*LP->solver());<br>
<br>
LP->assignSolver(cloned_solver, true /* Kill previous
solver */);<br>
memcpy(LP->bestSolution(),
LP->solver()->getColSolution(), n_cols *
sizeof(double));</small><br>
</blockquote>
It seems, that we are violating one or two unwritten laws of
memory management with CBC, but I am at loss as what we are
doing wrong here. Any help, hints, pointer to documentation,
etc. is highly appreciated.<br>
<br>
Cheers,<br>
Dirk Eßer<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Cbc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cbc@list.coin-or.org">Cbc@list.coin-or.org</a>
<a class="moz-txt-link-freetext" href="http://list.coin-or.org/mailman/listinfo/cbc">http://list.coin-or.org/mailman/listinfo/cbc</a>
</pre>
</blockquote>
<br>
</body>
</html>