Skip to content

Fix deadlock on duplicate PooledTransactions response - #151

Open
damilolaedwards wants to merge 1 commit into
ethpandaops:masterfrom
damilolaedwards:fix/execution-pooled-tx-deadlock
Open

Fix deadlock on duplicate PooledTransactions response#151
damilolaedwards wants to merge 1 commit into
ethpandaops:masterfrom
damilolaedwards:fix/execution-pooled-tx-deadlock

Conversation

@damilolaedwards

Copy link
Copy Markdown

Summary

handlePooledTransactions sent to the per-request channel while holding pooledTransactionsMux. A peer that replied twice to the same request ID could make the second send block forever on an unbuffered, already drained channel, while still holding the mutex. That wedged the whole session read loop, and the original caller's deferred cleanup then blocked forever trying to acquire the same lock.

Makes the channel buffered so the first reply never has to wait for the receiver to be ready, and makes the send non-blocking so any extra reply for a request that has already been answered is dropped instead of stalling the read loop. The map lookup and the send still happen under the same lock as before, so there is no window where a stale or closed channel could be sent to.

Test plan

  • Added a test that replays a duplicate response over a real handshake and confirms the mutex is still available afterward.
  • Confirmed the test fails against the previous code (deadlocks within a few seconds) and passes with the fix.
  • go build ./..., go vet ./..., and the full package test suite all pass.

handlePooledTransactions sent to the per-request channel while holding
pooledTransactionsMux. A peer that replied twice to the same request ID
could make the second send block forever on an unbuffered, already
drained channel, while still holding the mutex. That wedged the whole
session read loop, and the original caller's deferred cleanup then
blocked forever trying to acquire the same lock.

Make the channel buffered so the first reply never has to wait for the
receiver to be ready, and make the send non-blocking so any extra reply
for a request that has already been answered is dropped instead of
stalling the read loop.

Adds a test that replays a duplicate response over a real handshake and
confirms the mutex is still available afterward. Confirmed the test
fails against the previous behavior and passes with the fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant