[Scip] Assertion fails in RENS heuristic

Daniel Karch karch at math.tu-berlin.de
Fri Dec 16 14:43:13 MET 2011


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.

  Daniel

2011/12/15 Stefan Vigerske <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
>> http://listserv.zib.de/**mailman/listinfo/scip<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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20111216/83edebd5/attachment.html


More information about the Scip mailing list