Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add heapIndex with safety check #213

Merged
merged 6 commits into from
Mar 22, 2024
Merged

Add heapIndex with safety check #213

merged 6 commits into from
Mar 22, 2024

Commits on Mar 21, 2024

  1. add heapIndex with safety check

    @stevenlanders
    stevenlanders committed Mar 21, 2024
    Configuration menu
    Copy the full SHA
    ece9faf View commit details
    Browse the repository at this point in the history

  2. cleanup

    @stevenlanders
    stevenlanders committed Mar 21, 2024
    Configuration menu
    Copy the full SHA
    1de9d25 View commit details
    Browse the repository at this point in the history

  3. comment out for perf test

    @stevenlanders
    stevenlanders committed Mar 21, 2024
    Configuration menu
    Copy the full SHA
    cab27d2 View commit details
    Browse the repository at this point in the history

  4. add back perf improvement

    @stevenlanders
    stevenlanders committed Mar 21, 2024
    Configuration menu
    Copy the full SHA
    ee8694d View commit details
    Browse the repository at this point in the history

  5. fix nil test

    @stevenlanders
    stevenlanders committed Mar 21, 2024
    Configuration menu
    Copy the full SHA
    61c5d80 View commit details
    Browse the repository at this point in the history

  6. Use write-lock in (*TxPriorityQueue).ReapMax funcs (#209) 

    ReapMaxBytesMaxGas and ReapMaxTxs funcs in TxPriorityQueue claim
> Transactions returned are not removed from the mempool transaction
> store or indexes.

However, they use a priority queue to accomplish the claim
> Transaction are retrieved in priority order.

This is accomplished by popping all items out of the whole heap, and
then pushing then back in sequentially. A copy of the heap cannot be
obtained otherwise. Both of the mentioned functions use a read-lock
(RLock) when doing this. This results in a potential scenario where
multiple executions of the ReapMax can be started in parallel, and
both would be popping items out of the priority queue.

In practice, this can be abused by executing the `unconfirmed_txs` RPC
call repeatedly. Based on our observations, running it multiple times
per millisecond results in multiple threads picking it up at the same
time. Such a scenario can be obtained via the WebSocket interface, and
spamming `unconfirmed_txs` calls there. The behavior that happens is a
`Panic in WSJSONRPC handler` when a queue item unexpectedly disappears
for `mempool.(*TxPriorityQueue).Swap`.
(`runtime error: index out of range [0] with length 0`)

This can additionally lead to a `CONSENSUS FAILURE!!!` if the race
condition occurs for `internal/consensus.(*State).finalizeCommit`
when it tries to do `mempool.(*TxPriorityQueue).RemoveTx`, but
the ReapMax has already removed all elements from the underlying
heap. (`runtime error: index out of range [-1]`)

This commit switches the lock type to a write-lock (Lock) to ensure
no parallel modifications take place. This commit additionally updates
the tests to allow parallel execution of the func calls in testing,
as to prevent regressions (in case someone wants to downgrade the locks
without considering the implications from the underlying heap usage).
    @sigv @stevenlanders
    sigv authored and stevenlanders committed Mar 21, 2024
    Configuration menu
    Copy the full SHA
    5a5ba00 View commit details
    Browse the repository at this point in the history