[Scip] Assertion fails in RENS heuristic
Stefan Heinz
heinz at zib.de
Fri Dec 16 21:48:15 MET 2011
Hi Daniel,
On 12/16/2011 02:43 PM, Daniel Karch wrote:
> Hi,
>
> I "solved" the problem, although I don't know why it works.
> The only place where I created a SCIP_SOL was a heuristic, and
> disabling the heuristic temporarily fixed the problem.
> The code looked like this:
>
> SCIP_CALL( SCIPcreateSol(scip, &newsol, heur) );
> ...
> SCIP_CALL( SCIPaddSolFree(scip, newsol, &success) );
>
> I changed it to
>
> SCIP_CALL( SCIPcreateSol(scip, &newsol, heur) );
> ...
> SCIP_CALL( SCIPaddSol(scip, newsol, &success) );
> SCIP_CALL( SCIPfreeSol(scip, &newsol) );
>
> and now it works. This seems strange to me, but at least now I can use
> the heuristic again.
>
Yes that is strange. Is your heuristic a general purpose heuristic? If
so, you could send it to me which would help me to reconstruct the issue.
Stefan
> Daniel
>
> 2011/12/15 Stefan Vigerske <stefan at math.hu-berlin.de
> <mailto:stefan at math.hu-berlin.de>>
>
> 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 <mailto: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
> <http://www.math.hu-berlin.de/%7Estefan>
>
>
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
More information about the Scip
mailing list