Originally posted by: SystemAdmin

Hello, I'm experiencing what appears to be unexpected behavior with the CPX_PARAM_SOLNPOOLGAP parameter in the CPLEX callable library functionality (on two different Windows machines: 64-bit with CPLEX 12.3 installed, and 32-bit with CPLEX 12.4 installed).

After creating a MIP, solving it with several objectives and slightly modifying it with four new columns and rows, I then iteratively adjust its objective until a stopping condition is reached in an algorithm. All this seems to be working just fine according to the solution output as well as the .lp file that I output.

Here is where I am finding a problem. Using the final feasible region and objective, I then use the CPXpopulate command to generate some (actually, 10 as I specify with the CPX_PARAM_POPULATELIM parameter) alternative solutions which are feasible and of (ideally) relatively high quality. However I am observing a strange behavior from CPLEX, in that only certain double values for CPX_PARAM_SOLNPOOLGAP (namely, 0.1, 0.35, and 0.4) lead to the C++ code completing and generating (at least) 10 solutions. Any other values I've tried for this parameter generate an error message in VS2010 similar to this: "Unhandled exception at 0x0f31766d in XYZ.exe: 0xC0000005: Access violation reading location 0x00001da0." Additionally, the value for the status variable in the call ("status = CPXsetdblparam(env, CPX_PARAM_SOLNPOOLGAP, 0.2);") is nonzero ("1"), which as far as I understand indicates an error. I should also note that a similar behavior has been observed with certain values for the CPX_PARAM_SOLNPOOLAGAP parameter.

Can anyone offer me insight into why this is happening? Additionally, I should also mention that I have been unable to duplicate this behavior using the same settings in the interactive optimizer together with the generated .lp file.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

At first glance this looks like a memory corruption error. The valid range for the solution pool gap parameters is 0 through 1e75, so CPXsetdblparam() should not return non-zero. Moreover, '1' is not a valid return value for CPXsetdblparam(). It it returns non-zero then it should return a CPLEX error code, which is something larger than 1000.
So I suspect that somehow the call to CPXsetdblparam() is corrupted or accesses corrupted data. Do you have tools like purify or valgrind to check that you don't access corrupted memory?
If you try to reproduce the problem with the interactive you should use the SAV file format, not the LP format.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Hello, I've ported the code over to linux and ran the code. It now appears that the value of the status variable is 0 after the "status = CPXsetdblparam(env, CPX_PARAM_SOLNPOOLGAP, 0.24);" call. I am not sure why that was occurring yesterday, other than perhaps it was an issue with the VS2010 debugger (I'm now directly printing out to the console the value of the status variable).

So on linux I can reproduce the same strange error, where certain values for the solution pool's relative gap work fine (the code finishes normally), while others end abnormally (a segmentation fault). It appears that this is occurring in my call to CPXpopulate.

I also took the liberty to run valgrind on this code as follows: valgrind --leak-check=yes --log-file=valgrind.log ./VAPS_GP

which produced:

**********************
==3198==
==3198== HEAP SUMMARY:
==3198== in use at exit: 1,428 bytes in 6 blocks
==3198== total heap usage: 189 allocs, 183 frees, 370,937 bytes allocated
==3198==
==3198== Searching for pointers to 6 not-freed blocks
==3198== Checked 257,220 bytes
==3198==
==3198== 128 bytes in 1 blocks are definitely lost in loss record 1 of 2
==3198== at 0x4024106: memalign (vg_replace_malloc.c:581)
==3198== by 0x4024163: posix_memalign (vg_replace_malloc.c:709)
==3198== by 0x81B4E8A: _964c26aaa0b1aa887c1c6e88f7857cb8 (in /home/.../Project)
==3198== by 0x42FD867: ???
==3198==
==3198== 1,300 bytes in 5 blocks are definitely lost in loss record 2 of 2
==3198== at 0x4024F20: malloc (vg_replace_malloc.c:236)
==3198== by 0x85E8121: uprv_malloc_44_cplex (in /home/.../Project)
==3198==
==3198== LEAK SUMMARY:
==3198== definitely lost: 1,428 bytes in 6 blocks
==3198== indirectly lost: 0 bytes in 0 blocks
==3198== possibly lost: 0 bytes in 0 blocks
==3198== still reachable: 0 bytes in 0 blocks
==3198== suppressed: 0 bytes in 0 blocks
==3198==
==3198== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 20 from 7)
3198
3198 used_suppression: 20 dl-hack3-cond-1
==3198==
==3198== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 20 from 7)
**********************
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Since the segfaults seem to occur consistently, could you generate a backtrace for one of them? On Linux you would just do

you@home> gdb ./VAPS_GP
(gdb) run
... wait for SIGSEGV ...
(gdb) backtrace

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Here are the result of the backtrace in gdb:

...Some earlier optimization... Then:

*********
Populate: phase I
MIP start 'm1' defined solution with objective -4.3200e+11.
1 of 12 MIP starts provided solutions.
MIP start 'm1' defined initial solution with objective -4.3200e+11.
Tried aggregator 2 times.
MIP Presolve eliminated 52 rows and 144 columns.
MIP Presolve modified 25 coefficients.
Aggregator did 116 substitutions.
Reduced MIP has 288 rows, 688 columns, and 1449 nonzeros.
Reduced MIP has 240 binaries, 0 generals, 0 SOSs, and 0 indicators.
Probing time = 0.00 sec.
Tried aggregator 1 time.
Presolve time = 0.01 sec.

Program received signal SIGSEGV, Segmentation fault.
0x081ebb56 in _3c7c33e1181e301636b712bd8b86087a ()
(gdb) backtrace
#0 0x081ebb56 in _3c7c33e1181e301636b712bd8b86087a ()
#1 0x00000000 in ?? ()
(gdb)
*********
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Hi Daniel,

Do you see anything in the gdb backtrace that might be causing the difficulty that I mentioned earlier concerning the CPX_PARAM_SOLNPOOLGAP parameter? Thank you for your help!
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Hm, that stacktrace looks a little short to really tell anything. And the function in which the SIGSEGV occurs is too large to guess a reason for the segmentation fault.
If you can disclose your model then I could try to reproduce the issue here. In case you can disclose the data please do the following right before the offending populate call:

CPXwriteprob(env, lp, "model.sav", NULL);
CPXwritemipstarts(env, lp, "model.mst", 0, CPXgetnummipstarts (env, lp));
CPXwriteparam(env, lp, "model.prm");

Then attach the three generated files here. If you don't want to attach them here then you can also mail them directly to daniel(dot)junglas(at)de(dot)ibm(dot)com.
Maybe also try to install the latest version of CPLEX (12.4.0.1) and see if the problem persists.
#CPLEXOptimizers
#DecisionOptimization