Hard timeout abort
See original GitHub issueCurrently, Cozy will hang at the following state for a long time:
$ time cozy examples/select-flatmap.ds -t 10
Checking call legality...
Checking invariant preservation...
Done!
Adding query q...
STARTING IMPROVEMENT JOB q
updating with 1 new solutions
update order:
--> q
considering update 1/1...
SOLUTION FOR q AT 0:00:00.037117 [size=74]
----------------------------------------
_var131 : Bag<{ A : Int, B : String }> = Rs
_var132 : Bag<{ B : String, C : Int }> = Ss
_var133 : Bag<{ B : String, C : Int }> = Qs
_var134 : Bag<{ B : String, C : Int }> = Ws
return FlatMap {r -> FlatMap {s -> FlatMap {q -> Map {w -> ((r).A, (s).C, (q).B, (w).C)} (Filter {w -> (((q).B == (w).B) and ((r).A == 15))} (_var134))} (_var133)} (_var132)} (_var131)
----------------------------------------
Stopping jobs
requesting stop for ImproveQueryJob[q]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Waiting on 1 jobs...
--> ImproveQueryJob[q] [pid=26128]
Stopping SafeQueue...
Done!
Generating IR...
Inlining calls...
Generating code for extension types...
Concretization functions:
_var79 : Bag<{ A : Int, B : String }> = Rs
_var80 : Bag<{ B : String, C : Int }> = Ss
_var81 : Bag<{ B : String, C : Int }> = Qs
_var82 : Bag<{ B : String, C : Int }> = Ws
SelectFlatmap:
type R = { A : Int, B : String }
type S = { B : String, C : Int }
type Q = { B : String, C : Int }
type W = { B : String, C : Int }
state _var79 : Bag<{ A : Int, B : String }>
state _var80 : Bag<{ B : String, C : Int }>
state _var81 : Bag<{ B : String, C : Int }>
state _var82 : Bag<{ B : String, C : Int }>
query q():
FlatMap {r -> FlatMap {s -> FlatMap {q -> Map {w -> ((r).A, (s).C, (q).B, (w).C)} (Filter {w -> (((q).B == (w).B) and ((r).A == 15))} (_var82))} (_var81)} (_var80)} (_var79)
Number of improvements done: 1
cozy examples/select-flatmap.ds -t 10 51.85s user 0.34s system 99% cpu 52.625 total
I guess Cozy is waiting for Z3 to return – but this might far exceed the specified timeout (10s).
We should be able to let Cozy give up early, kill the Z3 job and output immediately after timeout.
NOTE: some hints on the semantic of timeout
https://github.com/CozySynthesizer/cozy/issues/52
Issue Analytics
- State:
- Created 4 years ago
- Comments:7
Top Results From Across the Web
Can the hard drive timeout be disabled in Linux (attempting ...
Unfortunately, when a hard drive (usually a virtual drive) is slow, Linux aborts requests to that drive after a timeout, possibly causing ...
Read more >What is Command Timeout Error and How to Fix It?
The attribute value indicates the number of operations aborted due to a hard disk drive (HDD) timeout. If you see this SMART attribute ......
Read more >AbortSignal.timeout() - Web APIs | MDN
The static AbortSignal.timeout() method returns an AbortSignal that will automatically abort after a specified time.
Read more >[LU-6084] Tests are failed due to 'recovery is aborted by hard timeout'
Many recovery tests start to fail because unexpected recovery abort due to hard timeout. This issue relates to the following test suite run: ......
Read more >Aborting a stuck method after a timeout - Stack Overflow
Update: If the method is using a resource like a COM port, and you abort the thread, it would result in a "Safe...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
OK. If I run into any problems I will leave a comment here. Thanks.
In the original example, it appears the job is actually busy converting the syntax tree into a Z3 query, so additionally:
(And perhaps we should look into optimizing encoding bag equality a little…)