The issue arrises when a stack analysis does only reach a fixpoint after a large amount of time (> specified timeout limit).
Assuming a normal contract analysis, the function analyse_graph (src/dataflow.py:45-176) gets called for analyzing the contract. The analysis performs stack analysis till a fixpoint is reached:
while i != settings.max_iterations:
loop_start_clock = time.clock()
i += 1
modified = stack_analysis(cfg)
modified |= cfg.clone_ambiguous_jump_blocks()
if not modified:
break
# If the next analysis step will require more than the remaining time
# or we have already exceeded our time budget, break out.
loop_time = time.clock() - loop_start_clock
elapsed = time.clock() - start_clock
if bail_time >= 0:
if elapsed > bail_time or 2 * loop_time > bail_time - elapsed:
...
break
However if the call modified = stack_analysis(cfg) takes exceptionally long (i.e. multiple hours since no fixpoint can be reached) the aborting checks will never be reached.
This pull requests hotfixes the issue by also checking the bailout time during the call to stack_analysis. However there are multiple things kind of wrong with it:
the check on line src/dataflow:78 (if elapsed > bail_time or 2 * loop_time > bail_time - elapsed: ) should actually circumvent the issue, however, the 2 * loop_time check actually is way to short since the stack analysis seems to grow exponentially
my hotfix always resets the bailout time for every call to stack_analysis, it does not consider previous calls
I would like some suggestions on how to address these issues.
This pull request fixes #53.
The issue arrises when a stack analysis does only reach a fixpoint after a large amount of time (> specified timeout limit).
Assuming a normal contract analysis, the function
analyse_graph
(src/dataflow.py:45-176) gets called for analyzing the contract. The analysis performs stack analysis till a fixpoint is reached:However if the call
modified = stack_analysis(cfg)
takes exceptionally long (i.e. multiple hours since no fixpoint can be reached) the aborting checks will never be reached.This pull requests hotfixes the issue by also checking the bailout time during the call to
stack_analysis
. However there are multiple things kind of wrong with it:if elapsed > bail_time or 2 * loop_time > bail_time - elapsed:
) should actually circumvent the issue, however, the2 * loop_time
check actually is way to short since the stack analysis seems to grow exponentiallystack_analysis
, it does not consider previous callsI would like some suggestions on how to address these issues.