In the next experiment, we attempt to put the program into an invalid live-loop state: We select the fourth iteration to be last one correctly working and we will perform a bit flip before the read in line 21, which is the 22th access to state; we flip the second bit. We expect the program to return four reports and then mute for the rest of its life. After adjusting the parameters, we notice that our elevator will simply pause that second and continues to operate normally! The reason is that state is apparently reloaded from memory each time. As we perform the bit flip on a temporary representation, the flip does not persist and vanishes in the next iteration.
In order to persist the flip, we need to call persist_flip(state, {2}) from inside of flip_value of the control script. Now, the bit flip successfully induces a live lock—the output stops and we have to terminate the program.
Compared to the first experiment, the last line of Fig. 2 proofs that there has been much more activity after the last output. If working under less deterministic circumstances, we can tell FITIn to stop the execution on exceeding a specified limit.
In this experiment, we could terminate the elevator prematurely after 105000 instructions by adding the following callback code to the control script: