I've built gecode from release/6.3.0 branch (specifically, f7f0d7c273d6844698f01cec8229ebe0b66a016a),
plus libminizinc 2.8.5 release, using clang-18 -O2 -UNDEBUG.
At least one minizinc test has issues, the last output is: (only one test is run at once)
spec/unit/regression/test_parout.mzn::default.1.cbc
[gw0] [ 64%] SKIPPED spec/unit/regression/test_parout.mzn::default.1.cbc
spec/unit/regression/var_self_assign_bug.mzn::default.0.gecode
[gw0] [ 64%] PASSED spec/unit/regression/var_self_assign_bug.mzn::default.0.gecode
spec/unit/regression/var_self_assign_bug.mzn::default.0.chuffed
[gw0] [ 64%] PASSED spec/unit/regression/var_self_assign_bug.mzn::default.0.chuffed
spec/unit/regression/var_self_assign_bug.mzn::default.0.cbc
[gw0] [ 64%] SKIPPED spec/unit/regression/var_self_assign_bug.mzn::default.0.cbc
<this is the last output. after a while, OOM happens>
While waiting for OOM killer to trigger (after fzn-gecode consumes 100+Gigs of RAM!),
this is the relevant output of ps:
I've built gecode from
release/6.3.0
branch (specifically, f7f0d7c273d6844698f01cec8229ebe0b66a016a), plus libminizinc 2.8.5 release, using clang-18-O2 -UNDEBUG
.At least one minizinc test has issues, the last output is: (only one test is run at once)
While waiting for OOM killer to trigger (after fzn-gecode consumes 100+Gigs of RAM!), this is the relevant output of
ps
:So it is indeed
tests/spec/unit/test-globals-float.mzn
.This raises a bigger issue: looking at
fzn-gecode
, is there really no memory limit handling?X-Ref: https://github.com/MiniZinc/libminizinc/issues/835