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
I took a quick look and this means that somehow TCP socket layer must be calling up for a receive indication even though the TcpConnection has already been deleted. But in the destruction it clearly calls CxPlatSocketDelete. Looking at the SocketDelete code path, it seems to have some special cases for UseTcp and I think it shouldn't. My guess here is that this is what results in sometimes TCP code not waiting for all cleanup to occur before cleanup
Describe the bug
A crash has occurred in our secnetperf automation during the TCP HPS tests.
I took a quick look and this means that somehow TCP socket layer must be calling up for a receive indication even though the
TcpConnection
has already been deleted. But in the destruction it clearly callsCxPlatSocketDelete
. Looking at theSocketDelete
code path, it seems to have some special cases forUseTcp
and I think it shouldn't. My guess here is that this is what results in sometimes TCP code not waiting for all cleanup to occur before cleanupAffected OS
Additional OS information
No response
MsQuic version
main
Steps taken to reproduce bug
Run netperf perf tests
Expected behavior
All succeed
Actual outcome
TCP regularly crashes or hangs.
Additional details
netpef run: https://github.com/microsoft/netperf/actions/runs/7596674678
Dump and symbols: https://github.com/microsoft/netperf/actions/runs/7596674678/artifacts/1183278444
secnetperf.exe.4376.dmp
dump (the other one is a hang, but I suspect this is the underlying cause)The text was updated successfully, but these errors were encountered: