You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Flex, orders of opposite direction get matched in the dealer::process_queue() function.
This function contains the while loop that traverses the order queues of opposite direction, matching orders with each other.
It is quite message-intensive function: for example, it generates at least 3 new messages for each partially matched order
(see dealer::make_deal), and on each loop iteration, it generates a message for every expired order found in the queue
(see dealer::extract_active_order).
The proposition of this issue is that in some circumstances, the process_queue() function may generate more messages
than allowed by the node, i.e. MAX_ACTIONS = 255.
(see https://github.com/tonlabs/ton-labs-executor/blob/e20b16b4d92cee8261e96916b118c344483e0013/src/transaction_executor.rs#L488)
If this happens, most probably, the Price smart-contract will not be able to match orders of this price level any further :
all future calls will run into the same transaction abort, leaving all the funds locked and this Price level locked.
Before doing the formal analysis, we thought that the number of generated messages is bounded by at least the deals_limit_
constant, but, it turns out, the loop iteration counter may go well beyond that value. And the reason is that the break statement is located under conditional that might not hold, leading to another loop iterations: https://github.com/tonlabs/flex/blob/3aaa20eb73e7498d08d39191d693f1efa7d016eb/flex/Price.cpp#L139
It is proposed to introduce some definitional bound for the number of iterations this loop may process, hence protecting
the action queue from possible overflow / deadlock condition.
The same holds for PriceXchg::process_queue().
The text was updated successfully, but these errors were encountered:
In Flex, orders of opposite direction get matched in the
dealer::process_queue()
function.This function contains the while loop that traverses the order queues of opposite direction, matching orders with each other.
It is quite message-intensive function: for example, it generates at least 3 new messages for each partially matched order
(see
dealer::make_deal
), and on each loop iteration, it generates a message for every expired order found in the queue(see
dealer::extract_active_order
).The proposition of this issue is that in some circumstances, the
process_queue()
function may generate more messagesthan allowed by the node, i.e. MAX_ACTIONS = 255.
(see https://github.com/tonlabs/ton-labs-executor/blob/e20b16b4d92cee8261e96916b118c344483e0013/src/transaction_executor.rs#L488)
If this happens, most probably, the Price smart-contract will not be able to match orders of this price level any further :
all future calls will run into the same transaction abort, leaving all the funds locked and this Price level locked.
Before doing the formal analysis, we thought that the number of generated messages is bounded by at least the
deals_limit_
constant, but, it turns out, the loop iteration counter may go well beyond that value. And the reason is that the
break
statement is located under conditional that might not hold, leading to another loop iterations:https://github.com/tonlabs/flex/blob/3aaa20eb73e7498d08d39191d693f1efa7d016eb/flex/Price.cpp#L139
It is proposed to introduce some definitional bound for the number of iterations this loop may process, hence protecting
the action queue from possible overflow / deadlock condition.
The same holds for
PriceXchg::process_queue()
.The text was updated successfully, but these errors were encountered: