Closed th4s closed 1 month ago
Most likelydecode_key_private
is called twice due to a race.
It happens under these conditions:
the Leader
calls commit
and causes the notifier to be set by self.notifier.set()
we would hope that select_biased!
in async-client
would start processing the notify
future
but at the same time the server closes the connection and rx_tls_fut
is processed instead which causes client.server_closed()
to be called , which calls commit
again while self.buffer
is not empty.
The fix is to not allow commit
to be called more than once, unless there is a reason to do so @sinui0
While working on #539 I encountered the same test hanging. I isolated it into a new investigation-branch.
investigation-branch
was branched off from #539 it is possible that the bug was introduced in #539.investigation-branch
, but the test still hangs. So it is possible that there is a different cause.While working on #539 I encountered the same test hanging. I isolated it into a new investigation-branch.
This is fixed now and was caused by the changes of #539. But the original bug from the trace_hang.txt
still needs to be adressed.
Closed by #568
When running the tls-mpc-test with a tracing configuration that emits
New
andClose
FmtSpans we were able to capture the following log trace_hang.txt.After filtering for lines that contain
decode_key_private
and writing all theseLeader
events into this file decode_key_private.txt and doing the same fordecode_key_blind
and writing theseFollower
events into this file decode_key_blind.txt I notice thatdecode_key_private
is called twice on theLeader
site (line 1 and 21). This is not true for the follower, where it is called only once (line 1). This is what causes the leader site to be hanging inot_receive_active_encodings
(line 14389 intrace_hang.txt
).The cause for this might be that commit which calls
decode_key_private
is called twice: