The -Q argument of pan is unreliable
jllang opened this issue · comments
It seems that for some models, the timeout argument (-Q) of pan does not work for all models. I'm currently using the GNU timeout tool to run pan without problems in my shell script.
can you give an example?
My model is rather complicated. I'm not sure how to reduce it into the minimum viable counter-example. The model is part of my master's thesis project and it's not public yet. I just replaced all d_steps with atomics to eliminate the possibility that this issue is caused by non-terminating d_steps. I ran pan with -Q1 and observed that it didn't stop after one minute (I waited for 1 min 24 s). Usually pan prints messages such as
Depth= 413311 States= 1e+06 Transitions= 3.23e+06 Memory= 785.788 t= 1.28 R= 8e+05
after every one million states, I guess. I noticed that with my model, I don't get these messages.
It looks like pan uses 100% CPU time on one core and the amount of memory it uses doesn't increase. Could this be an infinite loop?
it's possible, but most likely it's defined in the model, not in pan itself....
Now I ran pan for more than three hours with this output:
error: max search depth too small
^CInterrupted
(Spin Version 6.5.2 -- 6 December 2019)
Warning: Search not completed
+ Partial Order Reduction
Full statespace search for:
never claim + (disjointness)
assertion violations + (if within scope of claim)
acceptance cycles + (fairness disabled)
invalid end states - (disabled by never claim)
State-vector 136 byte, depth reached 9999999, errors: 0
20413 states, stored
76950 states, matched
97363 transitions (= stored+matched)
3.3227067e+11 atomic steps
hash conflicts: 3 (resolved)
Stats on memory usage (in Megabytes):
3.193 equivalent memory usage for states (stored*(State-vector + overhead))
2.566 actual memory usage for states (compression: 80.37%)
state-vector as stored = 104 byte + 28 byte overhead
128.000 memory used for hash table (-w24)
534.058 memory used for DFS stack (-m10000000)
664.597 total actual memory usage
pan: elapsed time 1.16e+04 seconds
pan: rate 1.7609118 states/second
real 193m12,372s
user 193m4,214s
sys 0m2,568s
It might be very well some problem in the model. I cannot reproduce this problem with a newer version of the same model.
If and when I have infinite loops in my model, pan should be able to detect that, right?
if the number of states reached isn't changing (say for the last two of those hours), that would be clear evidence of being stuck in an infinite loop somewhere,....
After approximately a four and half hours, pan managed to reach only 30942 states. It's more than what's shown above, so pan seems to be making progress, albeit very slowly. It seems that the -Q flag doesn't stop pan after it has exceeded the time limit.
suspicious, but i'd need a small example to be able to reproduce it, so that it can be fixed....