Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propagator fails when lookahead is enabled. #45

Closed
rkaminsk opened this issue Apr 27, 2019 · 6 comments
Closed

Propagator fails when lookahead is enabled. #45

rkaminsk opened this issue Apr 27, 2019 · 6 comments

Comments

@rkaminsk
Copy link
Member

The runtime check

POTASSCO_REQUIRE(front_ == INT32_MAX || (dl - level_) == 1, "Propagate must be called on each level");

fires if a propagator is used together with lookahead (solver.6 in the portfolio).

If you need an example, I can provide something but in its current form there is quite some setup required to get it running.

@BenKaufmann
Copy link
Contributor

A (preferably) small example would be highly appreciated.

@rkaminsk
Copy link
Member Author

I'll try to come up with something. So far I can tell that the problem appears when solving incrementally with lookahead enabled. It consistently happens at the beginning of the second solving step. It is either the above runtime error or an assertion:

void Clasp::Lookahead::splice(Clasp::Lookahead::NodeId): Assertion `ul != UINT32_MAX' failed.

@rkaminsk
Copy link
Member Author

Please have a look at the lookahead-bug branch in clingo-dl. The project should build fine on both linux and windows. If you want to avoid installing re2c and bison you can apply the windows.patch.1 after checking out the submodules. The example to reproduce the bug itself is tiny.

@BenKaufmann
Copy link
Contributor

Thanks. Will try to give you some feedback by the end of this week.

BenKaufmann added a commit that referenced this issue May 1, 2019
* Generalize implementation of undo stack in Clingo propagator to
  correctly handle literals that are (temporarily) assigned/unassigned
  during lookahead but are actually never otherwise processed by the
  propagator.
@BenKaufmann
Copy link
Contributor

I hopefully found and fixed the problem. Could you please do some further testing?

@rkaminsk
Copy link
Member Author

rkaminsk commented May 1, 2019

Thanks. I think that clingo-dl is currently our most sophisticated propagator. But testing with lookahead is a bit difficult because with large instances it slows down solving too much. But maybe @wanko and @MaxOstrowski can try some lookahead options on smaller instances (e.g. --lookahead=atom,100 possible combined with multithreading). Feedback would be appreciated. (Having this bug free is important to run with -t<n> for <n> >= 6 without crashes.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants