<div dir="ltr">I apologize; I am not sure my report is a bug. In the case of changing a single objective coefficient (at a time), the proper modification to whatsChanged_ seems to be done in ClpSimplex (I had been looking at ClpModel). I am still getting a memory error, and I am trying to figure out how it happens.<div><br></div><div>In case someone has any suggestions, below is the (abridged) valgrind output, which says that memory is being written to after it has been deleted. In particular, the issue appears to be with the call "alternateWeights_->clear();" at ClpPrimalColumnSteepest.cpp:3041, which seems to be accessing memory freed via a conditionalDelete() of "nextCount_" at CoinFactorization1.cpp:1734 (and 1735, for lastCount_). I am not sure how these arrays are connected. </div><div><br></div><div>I would appreciate any advice, and thank you,</div><div>Alex</div><div><br></div><div><div>==22103== 7 errors in context 1 of 2:</div><div>==22103== Invalid write of size 8</div><div>==22103==    at 0xA39E10: CoinIndexedVector::clear() (CoinIndexedVector.cpp:51)</div><div>==22103==    by 0x8B742D: ClpPrimalColumnSteepest::saveWeights(ClpSimplex*, int) (ClpPrimalColumnSteepest.cpp:3041)</div><div>==22103==    by 0x95939D: ClpSimplexPrimal::statusOfProblemInPrimal(int&, int, ClpSimplexProgress*, bool, int, ClpSimplex*) (ClpSimplexPrimal.cpp:1636)</div><div>==22103==    by 0x953FCE: ClpSimplexPrimal::primal(int, int) (ClpSimplexPrimal.cpp:361)</div><div>==22103==    by 0x8DC44E: ClpSimplex::primal(int, int) (ClpSimplex.cpp:5971)</div><div>==22103==    by 0x70A3E6: OsiClpSolverInterface::resolve() (OsiClpSolverInterface.cpp:1056)</div><div>// abridged</div><div>==22103==  Address 0x784dbc8 is 744 bytes inside a block of size 2,248 free'd</div><div>==22103==    at 0x4A07D8E: operator delete[](void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)</div><div>==22103==    by 0xA42F12: CoinArrayWithLength::conditionalDelete() (CoinIndexedVector.cpp:1841)</div><div>==22103==    by 0x9E9CE2: CoinFactorization::cleanup() (CoinFactorization1.cpp:1734)</div><div>==22103==    by 0x9E7E63: CoinFactorization::factor() (CoinFactorization1.cpp:1184)</div><div>==22103==    by 0x8575AD: ClpFactorization::factorize(ClpSimplex*, int, bool) (ClpFactorization.cpp:2255)</div><div>==22103==    by 0x8C8254: ClpSimplex::internalFactorize(int) (ClpSimplex.cpp:1992)</div><div>==22103==    by 0x9554CF: ClpSimplexPrimal::statusOfProblemInPrimal(int&, int, ClpSimplexProgress*, bool, int, ClpSimplex*) (ClpSimplexPrimal.cpp:855)</div><div>==22103==    by 0x953FCE: ClpSimplexPrimal::primal(int, int) (ClpSimplexPrimal.cpp:361)</div><div>==22103==    by 0x8DC44E: ClpSimplex::primal(int, int) (ClpSimplex.cpp:5971)</div><div>==22103==    by 0x70A3E6: OsiClpSolverInterface::resolve() (OsiClpSolverInterface.cpp:1056)</div></div><div><br></div><div><div>==22103== 8 errors in context 2 of 2:</div><div>==22103== Invalid write of size 8</div><div>==22103==    at 0xA39DF3: CoinIndexedVector::clear() (CoinIndexedVector.cpp:50)</div><div>==22103==    by 0x8B742D: ClpPrimalColumnSteepest::saveWeights(ClpSimplex*, int) (ClpPrimalColumnSteepest.cpp:3041)</div><div>==22103==    by 0x95939D: ClpSimplexPrimal::statusOfProblemInPrimal(int&, int, ClpSimplexProgress*, bool, int, ClpSimplex*) (ClpSimplexPrimal.cpp:1636)</div><div>==22103==    by 0x953FCE: ClpSimplexPrimal::primal(int, int) (ClpSimplexPrimal.cpp:361)</div><div>==22103==    by 0x8DC44E: ClpSimplex::primal(int, int) (ClpSimplex.cpp:5971)</div><div>==22103==    by 0x70A3E6: OsiClpSolverInterface::resolve() (OsiClpSolverInterface.cpp:1056)</div><div>// abridged</div><div>==22103==  Address 0x784e818 is 1,576 bytes inside a block of size 2,248 free'd</div><div>==22103==    at 0x4A07D8E: operator delete[](void*) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)</div><div>==22103==    by 0xA42F12: CoinArrayWithLength::conditionalDelete() (CoinIndexedVector.cpp:1841)</div><div>==22103==    by 0x9E9CF7: CoinFactorization::cleanup() (CoinFactorization1.cpp:1735)</div><div>==22103==    by 0x9E7E63: CoinFactorization::factor() (CoinFactorization1.cpp:1184)</div><div>==22103==    by 0x8575AD: ClpFactorization::factorize(ClpSimplex*, int, bool) (ClpFactorization.cpp:2255)</div><div>==22103==    by 0x8C8254: ClpSimplex::internalFactorize(int) (ClpSimplex.cpp:1992)</div><div>==22103==    by 0x9554CF: ClpSimplexPrimal::statusOfProblemInPrimal(int&, int, ClpSimplexProgress*, bool, int, ClpSimplex*) (ClpSimplexPrimal.cpp:855)</div><div>==22103==    by 0x953FCE: ClpSimplexPrimal::primal(int, int) (ClpSimplexPrimal.cpp:361)</div><div>==22103==    by 0x8DC44E: ClpSimplex::primal(int, int) (ClpSimplex.cpp:5971)</div><div>==22103==    by 0x70A3E6: OsiClpSolverInterface::resolve() (OsiClpSolverInterface.cpp:1056)</div><div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 2, 2017 at 2:11 AM Aleksandr M. Kazachkov <<a href="mailto:akazachk@cmu.edu" target="_blank">akazachk@cmu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all, I have a possible bug report, as well as a (related) question.<div><br></div><div>1. In OsiClpSolverInterface::setObjCoeff (when setting just one coefficient), I think (unless I am misunderstanding something, in which case I apologize) that line 6125</div><div><br></div><div>  modelPtr_->whatsChanged_ &= 0xffff;</div><div><br></div><div>should be</div><div><br></div><div>  modelPtr_->whatsChanged_ &= (0xffff&~64);<br></div><div><br></div><div>same as in OsiClpSolverInterface::setObjective, as the 64 bit corresponds to "OBJECTIVE_SAME". This was (ultimately) causing a memory corruption error for me after I would set the objective (coefficient by coefficient, because my objective is sparse), resolve, then delete my solver object.</div><div><br></div><div>2. I am working with an instance in n-dimensional space, but the majority of these columns are empty. In my context, I will be solving the instance repeatedly with different objective functions. The first solve is an "initialSolve" and subsequent solves, unless some issue is encountered, are "resolve" calls.</div><div><br></div><div>Is it better (faster in the long run, given the multiple resolves) to preprocess the instance in advance to have no empty columns, or is that a waste of time? My first thought was that it would not make much difference since internally the matrix is kept in sparse form and anyway presolve would catch this, but I am not sure I am right.</div><div><br></div><div>Thank you in advance for your input,</div><div>Aleksandr Kazachkov</div></div></blockquote></div></div></div></div>