Originally posted by: SystemAdmin

When running Memcheck (a memory error detector) using Valgrind 3.8.1, I encounter very large (~284,000,000 bytes) memory leaks running the attached .cpp code using CPLEX (specifically, I use version 12.5 in conjunction with Concert Technology). I have reallocated (through use of .end() statements) memory from nearly all objects, but I am still encountering this extremely large memory leak. Since I am adding approximately 4000 cuts when solving my subproblem inside of the ILOLAZYCONSTRAINTCALLBACK4 macro, I have a feeling that the memory has to do with this process, though I am not sure how it would be leading to memory leak, as I am using the .end() method on every cut added (e.g., add(x<=expr).end()). Is it possible that after these cuts are added to the master problem, the cuts (which are added at each integer node of CPLEX's branch and bound tree) are somehow not deleted when using .end() method on the IloModel, IloCplex, and even IloEnv objects of the master problem? Any help resolving this memory leak issue (or even guidance in the right direction) would be greatly appreciated.

Thank you for your time,
Andrew
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

I took a quick look at your code. It is way too large to quickly tell where memory is lost. But if you run valgrind with option '--leak-check=full' it should give backtraces to where the leaked memory was allocated. So the first thing to do is to run with this option and double check the places at which valgrind points. If you cannot figure out what is wrong then maybe post the backtraces here.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Daniel,

Thank you for the tip. I ran valgrind with --leak-check=full. I have a feeling it is in the callback itself judging from the output below (I only including a snippet of it, since this seems to contribute to the largest chunk of the memory leak):

==14161== 190,410,936 (99,013,824 direct, 91,397,112 indirect) bytes in 952,056 blocks are definitely lost in loss record 39 of 39
==14161== at 0x4C279EE: malloc (vg_replace_malloc.c:270)
==14161== by 0x493798: IloCplexCallbackManager::ParallelEnv::alloc(unsigned long) (in /home/romich/OPoSM/MF_20130311)
==14161== by 0xF181D1: operator+(IloNumExprArg, double) (in /home/romich/OPoSM/MF_20130311)
==14161== by 0xF18493: operator-(IloNumExprArg, double) (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x441CE2: checkSPI::main() (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x47F003: IloCplexCallbackManager::call(IloCplex::CallbackI*) (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x480CF1: lazyconstraintcallback (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x79E579: _34d6108b800abb67414efa6c4c6f7112 (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x846D0F: _5802e8c70437348dc0dbfb43e4ff1349 (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x7A9258: _33647440a26d640acca1886f9152d44a (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x7B1296: _caf3e34e565d7f85f474237f790aa558 (in /home/romich/OPoSM/MF_20130311)
==14161== by 0x7A64BC: _abe84a0e53b2d89edf8a270c824b7bd8 (in /home/romich/OPoSM/MF_20130311)
If you could, by any chance, help me a little with the interpretation of the above output, it would be greatly appreciated. Is ":270" in the third line of the output referring to line 270 of my actual code file?

Thank you for your time,
Andrew
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

"vg_replace_malloc.c:270" means "line 270 in file vg_replace_malloc.c" which is a valgrind-internal file. You should compile your code in debug mode (using -g, or even -g3 -ggdb if you are using gcc/g++), then you should also get line numbers for the places in your code.
In the meantime I ran your code through valgrind here and found two problematic places:
1. Near line 538 you have

expr+=SP_solver.getValue(u[qrIndex][N*(i-1)+jIndex])*(1-((x1[i] - xi1[i] - x1[jIndex] + xi1[jIndex] + x2[i] - xi2[i] - x2[jIndex] + xi2[jIndex] - D1)/(D0-D1)));

This leaks memory. One way to avoid leakage is to rewrite as

IloExpr tmp = (1-((x1[i] - xi1[i] - x1[jIndex] + xi1[jIndex] + x2[i] - xi2[i] - x2[jIndex] + xi2[jIndex] - D1)/(D0-D1))); expr+=SP_solver.getValue(u[qrIndex][N*(i-1)+jIndex])* tmp; 
// u part tmp.end();

2. Near line 563 you have

expr+= SP_solver.getValue(v1[N*(i-1)+jIndex])*(2*(x1[i] - xi1[i]) - 2*(x1[jIndex] - xi1[jIndex])); 
//v_ij,1 part of obj expr+= SP_solver.getValue(v2[N*(i-1)+jIndex])*(2*(x2[i] - xi2[i]) - 2*(x2[jIndex] - xi2[jIndex])); 
//v_ij,2 part of obj

This is basically the same as above and does leak memory (according to valgrind). Rewriting as

IloExpr tmp = (2*(x1[i] - xi1[i]) - 2*(x1[jIndex] - xi1[jIndex])); expr+= SP_solver.getValue(v1[N*(i-1)+jIndex])*tmp; 
//v_ij,1 part of obj tmp.end(); tmp = (2*(x2[i] - xi2[i]) - 2*(x2[jIndex] - xi2[jIndex])); expr+= SP_solver.getValue(v2[N*(i-1)+jIndex])*tmp; 
//v_ij,2 part of obj tmp.end();

made the leaks go away.
After changing the two places above valgrind did no longer report any leaks for me.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Daniel,

You are very good at what you do! After implementing your fix, I am also no longer seeing any memory leaks. Thank you so much; you have been a tremendous help!
#CPLEXOptimizers
#DecisionOptimization