[Scip] Assertion fails in RENS heuristic

Thu Dec 15 16:04:30 MET 2011

Hi,

the heuristic is not new, but the default of the uselprows parameter 
changed to FALSE, so that it now works as LNS heuristic on the CIP 
instead of the MIP relaxation. That is, it copies the problem itself 
into a new SCIP instance, fixes variables there, presolves and searches, 
instead of creating a SCIP instance from the current LP.

My guess for the assert is, that some solution (SCIP_SOL) was created in 
the subscip but not freed before the transformed subscip is freed.
Are you using any plugins that do not come with SCIP (e.g., a 
fsg-reader) and implement the copy callbacks? Maybe you can check if 
they create solutions but not always free them.

With gdb you should also be able to inspect the solutions in the 
primal->existingsols array. E.g., primal->existingsols[0]->heur should 
be a pointer to the heuristic that found the solution, if created by 
one. primal->existingsols[0]->solorigin may also be helpful.

Stefan

> Hello everyone,
>
> I just updated from SCIP 2.0.1 to 2.1.0 and unfortunately it introduced
> some problems.
> Some of them I could work around, they all seem to be triggered by the RENS
> heuristic (is it new?).
>
> More precisely, the assertion gets thrown in primal.c:
>
>    time | node  | left  |LP iter|LP it/n| mem |mdpt |frac |vars |cons |cols
> |rows |cuts |confs|strbr|  dualbound   | primalbound  |  gap
> K13.3s|     1 |     0 |     0 |     - |  12M|   0 |   - | 723 |1372 |   0 |
>    0 |   0 |   0 |   0 |      --      | 1.519167e+00 |    Inf
>   13.4s|     1 |     0 |   571 |     - |  13M|   0 | 280 | 723 |1372 | 723
> |1364 |   0 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   13.4s|     1 |     0 |   571 |     - |  13M|   0 | 280 | 723 |1372 | 723
> |1364 |   0 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   14.7s|     1 |     0 |   615 |     - |  13M|   0 | 172 | 723 |1372 | 723
> |1492 | 128 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   15.4s|     1 |     0 |   628 |     - |  13M|   0 | 164 | 723 |1372 | 723
> |1496 | 132 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   16.0s|     1 |     0 |   634 |     - |  13M|   0 | 158 | 723 |1372 | 723
> |1497 | 133 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   16.6s|     1 |     0 |   650 |     - |  13M|   0 | 164 | 723 |1372 | 723
> |1498 | 134 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   17.2s|     1 |     0 |   677 |     - |  13M|   0 | 186 | 723 |1372 | 723
> |1501 | 137 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
>   17.9s|     1 |     0 |   679 |     - |  13M|   0 | 182 | 723 |1372 | 723
> |1503 | 139 |   0 |   0 | 8.287500e-01 | 1.519167e+00 |  83.31%
> E18.2s|     1 |     0 |  1219 |     - |  13M|   0 | 182 | 723 |1372 | 723
> |1503 | 139 |   0 |   0 | 8.287500e-01 | 9.525000e-01 |  14.93%
> scipmincon.linux.x86_64.gnu.dbg.cpx: src/scip/primal.c:143: SCIPprimalFree:
> Assertion `(*primal)->nexistingsols == 0' failed.
>
> The stack trace is:
>
> #0  0x00002aaaabf9e9d5 in raise () from /lib64/libc.so.6
> #1  0x00002aaaabf9fed6 in abort () from /lib64/libc.so.6
> #2  0x00002aaaabf97235 in __assert_fail () from /lib64/libc.so.6
> #3  0x00000000005c0ec5 in SCIPprimalFree (primal=0x2238fb0,
> blkmem=0x1ac8730) at src/scip/primal.c:143
> #4  0x00000000005e76ab in freeTransform (scip=0x2238f40) at
> src/scip/scip.c:7282
> #5  0x00000000005e8fc3 in SCIPfreeTransform (scip=0x2238f40) at
> src/scip/scip.c:7744
> #6  0x00000000005dc124 in SCIPfreeProb (scip=0x2238f40) at
> src/scip/scip.c:4357
> #7  0x00000000005ce67f in SCIPfree (scip=0x7fffffffd018) at
> src/scip/scip.c:586
> #8  0x000000000080c5e3 in SCIPapplyRens (scip=0x1464010, heur=0x1537bd0,
> result=0x7fffffffd260, minfixingrate=0.5, minimprove=0.01, maxnodes=5000,
> nstallnodes=500, startsol=108 'l', binarybounds=1, uselprows=0) at
> src/scip/heur_rens.c:567
> #9  0x000000000080cafd in heurExecRens (scip=0x1464010, heur=0x1537bd0,
> heurtiming=44, result=0x7fffffffd260) at src/scip/heur_rens.c:695
> #10 0x000000000050d36d in SCIPheurExec (heur=0x1537bd0, set=0x14681d0,
> primal=0x163fc90, depth=0, lpstateforkdepth=-1, heurtiming=44,
> ndelayedheurs=0x7fffffffd25c, result=0x7fffffffd260) at src/scip/heur.c:398
> #11 0x0000000000649729 in SCIPprimalHeuristics (set=0x14681d0,
> stat=0x156bb20, primal=0x163fc90, tree=0x1774cf0, lp=0x17b0810,
> nextnode=0x0, heurtiming=44, foundsol=0x7fffffffd418) at
> src/scip/solve.c:241
> #12 0x0000000000654e37 in solveNode (blkmem=0x14661b0, set=0x14681d0,
> stat=0x156bb20, origprob=0x156c570, transprob=0x1797030, primal=0x163fc90,
> tree=0x1774cf0, lp=0x17b0810, relaxation=0x163f710, pricestore=0x186f7d0,
> sepastore=0x186f860, branchcand=0x17cc0f0, cutpool=0x186f8e0,
> conflict=0x1774ec0, eventfilter=0x16a03c0, eventqueue=0x165bdc0,
> cutoff=0x7fffffffd5bc, unbounded=0x7fffffffd5b8, infeasible=0x7fffffffd5b4,
> restart=0x7fffffffd748, afternodeheur=0x7fffffffd5ac) at
> src/scip/solve.c:3327
> #13 0x0000000000657623 in SCIPsolveCIP (blkmem=0x14661b0, set=0x14681d0,
> stat=0x156bb20, mem=0x1464120, origprob=0x156c570, transprob=0x1797030,
> primal=0x163fc90, tree=0x1774cf0, lp=0x17b0810, relaxation=0x163f710,
> pricestore=0x186f7d0, sepastore=0x186f860, cutpool=0x186f8e0,
> branchcand=0x17cc0f0, conflict=0x1774ec0, eventfilter=0x16a03c0,
> eventqueue=0x165bdc0, restart=0x7fffffffd748) at src/scip/solve.c:3878
> #14 0x00000000005e8628 in SCIPsolve (scip=0x1464010) at src/scip/scip.c:7541
> #15 0x000000000062dd9b in fromCommandLine (scip=0x1464010,
> filename=0x7fffffffe29d "../fsg/polska.fsg") at src/scip/scipshell.c:135
> #16 0x000000000062e5cd in SCIPprocessShellArguments (scip=0x1464010,
> argc=3, argv=0x7fffffffde38, defaultsetname=0xfd751e "scipmincon.set") at
> src/scip/scipshell.c:341
> #17 0x00000000004088f4 in runSCIP (argc=3, argv=0x7fffffffde38) at
> src/cppmain.cpp:82
> #18 0x0000000000408abd in main (argc=3, argv=0x7fffffffde38) at
> src/cppmain.cpp:120
>
> This is hard to debug for me, since I can't deduce which part of my code is
> responsible for the error, although I suspect that it has to do with the
> scip_trans method in my problem data class.
>
> Does anyone know what this error means and how I can prevent it? It occurs
> only in debugging.
>
> Thanks in advance,
>
>    Daniel Karch
>
>
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip

-- 
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan