Optimization Bug

[Roland Kaminski]

There seems to be a bug with clasp's --opt-mode=optN with the program bug.sm.gz.

• clasp bug.sm 0 --opt-mode=optN
  • results incorrectly in 102 solutions (activating --trans-ext=all leads to the correct 120 solutions)
  • solving in multi-threaded mode (e.g., -t2) leads to random amounts of solutions
• a clasp binary with assertion enabled and two threads leads to an assertion
• this bug seems to affect all clasp 3 releases

➜ clasp bug.sm 0 -t2
clasp: /build/clingo-wM7dVL/clingo-5.5.0/clasp/clasp/util/pod_vector.h:243: bk_lib::pod_vector<T, Allocator>::reference bk_lib::pod_vector<T, Allocator>::operator[](bk_lib::pod_vector<T, Allocator>::size_type) [with T = bk_lib::left_right_sequence<Clasp::ClauseWatch, Clasp::GenericWatch, 0>; Allocator = std::allocator<bk_lib::left_right_sequence<Clasp::ClauseWatch, Clasp::GenericWatch, 0> >; bk_lib::pod_vector<T, Allocator>::reference = bk_lib::left_right_sequence<Clasp::ClauseWatch, Clasp::GenericWatch, 0>&; bk_lib::pod_vector<T, Allocator>::size_type = unsigned int]: Assertion `n < size()' failed.

[Roland Kaminski]

Here is also a scaled down version of the program that exhibits the same problem. The non-ground version consists of the following rules:

pref(1..5,1..4).

{ match(X,Y) : pref(X,Y) }.
:- match(X,_), 2 { match(X,_) }.
:- match(_,Y), 2 { match(_,Y) }.

path(Agent1,Agent2) :- match(Agent1,House1), match(Agent2,House2).
path(Agent1,Agent3) :- path(Agent1,Agent2), match(Agent2,House2), match(Agent3,House3).

#maximize { 1,X,Y : match(X,Y) }.
#show match/2

The rules deriving path/2 lead to 5 SCCs but are otherwise completely useless. Removing them results in the correct number of solutions.

➜ clasp bug.aspif --opt-mode=optN 0 -q
clasp version 3.3.5
Reading from bug.aspif
Solving...
OPTIMUM FOUND

Models       : 121
  Optimum    : yes
  Optimal    : 116
Optimization : -4

The program bug.aspif.gz should have 120 solutions with cost -4.

[Benjamin Kaufmann]

@rkaminsk
The missing models are due to a bug in the handling of loop formulas (option --loops=shared), where loop formulas learnt and tagged during the optimization step are not correctly removed when switching to the enumaration step.
I have created a branch with a primitive workaround but I'll try to take a closer look again next weekend.

With the current release, a simple workaround would be to switch to a different loop mode (--loops=common or --loops=distinct). This does not solve the assertion, though.

[Roland Kaminski]

Thanks for having a look. We also have a problem with multi-threaded unsatisfiable core based minimization in potassco/clingcon#58. I still wanted to have a look to make this one a bit more accessible but did not find the time yet. Max already tried something.