Strange problem on late update

[winnnnnny]

Sorry for disturbing you!
In some cases, I observed that the update did not conduct in time.
Here is an example

a = sint(0)
b = sint(10)
# It is strange that without the following two lines, the unexpected behavior won't occur.
c = sint(0)
c.update((a >= b))
d = sint(10)
var1 = sint(0)
# In the following line, var1 should be included in the right sight. Otherwise, the unexpected behavior won't occur. 
# var2 now is 1
var2 = sint(var1 == a)
# In the following line, both var1 and var2 should be included in the right sight. Otherwise, the unexpected behavior won't occur.
d.update(var2 - var1)
# var1 is updated with a value comparison first. If not, then the unexpected behavior won't occur.
var1.update(sint(10) <= a)
# var1 now should be 10
var1.update(b)
# var2 is 1 correctly
print_ln('var2: %s', var2.reveal())
# var1 is 0 incorrectly, it is still the value from sint(10) <= a
print_ln('var1: %s', var1.reveal())
# the result from the following logic is wrong. It should be 0 since var2<var1. However, it is 1 incorrectly.
# If the logic only including (var2 > var1), then the result will be correct and all the printing will be correct.
print_ln('judge: %s', ((var2 > var1).bit_and((var2 >= 1))).reveal())
# The content in the following if block should not be accessed since the result is False. However, it is accessed unexpectedly.
@if_(((var2 > var1).bit_and((var2 >= 1))).reveal())
def _():
    print_ln('This block should not be accessed')

The result is shown below.

./Scripts/mascot.sh test 
Running /home/mp-spdz/Scripts/../mascot-party.x 0 test -pn 10167 -h localhost -N 2
Running /home/mp-spdz/Scripts/../mascot-party.x 1 test -pn 10167 -h localhost -N 2
Using security parameter 40
var2: 1
var1: 0
judge: 1
This block should not be accessed
Significant amount of unused triples of SPDZ gfp. For more accurate benchmarks, consider reducing the batch size with --batch-size.
Note that some protocols have larger minimum batch sizes.
Significant amount of unused bits of SPDZ gfp. For more accurate benchmarks, consider reducing the batch size with --batch-size.
Note that some protocols have larger minimum batch sizes.
The following benchmarks are including preprocessing (offline phase).
Time = 0.90959 seconds 
Data sent = 39.0634 MB in ~175 rounds (party 0 only; use '-v' for more details)
Global data sent = 78.1268 MB (all parties)
This program might benefit from some protocol options.
Consider adding the following at the beginning of your code:
        program.use_edabit(True)

It seems that it is hard to trigger this unexpected behavior. Sorry for taking your time to read such a long code. Is this a bug?

[mkskeller]

Thank you for raising this. You should find that 80fa53c fixes it.

[winnnnnny]

Thank you for repairing this!