Open danwt opened 3 years ago
Ah, that's true. Would you prefer seeing: "No way to extend symbolic computation".
Ah, that's true. Would you prefer seeing: "No way to extend symbolic computation".
I think that's just another phrasing of what is already given. I think the problem is that from the current message it's not very obvious that the deadlock is only occurring because previous solutions have been thrown out. It might make a user think their system model has a deadlock when in fact it doesn't.
With flag --no-deadlock
introduced in #1679 this now prints:
All executions are shorter than the provided bound. W@12:42:41.962
Found 2 error(s) I@12:42:41.963
The outcome is: ExecutionsTooShort I@12:42:41.966
@konnov I'd say this is resolved?
Actually, it's not. With --no-deadlock
, Apalache finishes with an OK result, even if there were previous counter-examples:
All executions are shorter than the provided bound. W@12:50:52.595
Found 2 error(s) I@12:50:52.598
The outcome is: ExecutionsTooShort I@12:50:52.601
Checker reports no error up to computation length 10 I@12:50:52.601
It took me 0 days 0 hours 0 min 4 sec I@12:50:52.603
Total time: 4.790 sec I@12:50:52.603
EXITCODE: OK
Oops. The fix was not good then
@shonfeder, given the recent refactoring of the configuration options, what would be the optimal place for doing the following: if --max-error=k
is set and k > 1
, set --no-deadlock
to true.
@shonfeder, given the recent refactoring of the configuration options, what would be the optimal place for doing the following: if
--max-error=k
is set andk > 1
, set--no-deadlock
to true.
This is also an issue when passing a transition filter. Maybe deadlock checking should be off by default? All other checks we do (invariants, ...) are off by default.
Given that deadlock detection makes an additional call (and it's is incomplete anyways), it seems to be a good idea to me to set --no-deadlock=true
by default.
what would be the optimal place for doing the following: if --max-error=k is set and k > 1, set --no-deadlock to true.
Really depends on the program logic. If it is an invariant of anything that takes checker options, then I think it should go in the converstion from configurations to "option groups":
Description
When you generate multiple counterexamples with --max-error=k, and a View operator, if it is not possible to generate at least k counterexamples then the log contains this line 'Found a deadlock. No SMT model. E@14:57:23.621', which makes sense but is a bit confusing.
Input specification
The command line parameters used to run the tool
apalache-mc check --max-error=3 --view=View --inv=IsThree 2PossibleTraces.tla
Expected behavior
A nice log message like 'max counterexamples have been generated for the given view'
Log files
System information
apalache-mc version
]: APALACHE version 0.15.12 build 05d50b2