Closed nibanks closed 1 year ago
Is it plausible that the test failure D:\a\msquic\msquic\src\test\bin\quic_gtest.cpp(2123): error: Value of: DriverClient.Run(( ((0x00000012) << 16) | ((( 0x0002 )) << 14) | ((114) << 2) | (0) ))
led to the chain reaction that gave the erroneous logs?
Also interesting how this same test passes in another PR, wondering if the DriverClient.run is the flaky part? https://github.com/microsoft/msquic/actions/runs/6366747961/job/17284890779?pr=3889
I am doubting whether its the core code that led to this, or the flaky test code (DriverClient.run error) that led to this.
Would be nice to get a test failure of JUST the datatest client timeout, without additional confounding variables like the DriverClient failure.
Describe the bug
During a unrelated PR run, this test failed once (in kernel mode) and 2 other kernel builds crashed ([1] [2]), which may be related (we don't know for sure).
From quic.log, I see:
I noticed a few things from the logs:
QUIC_TRACE_API_TYPE
is not in sync withmap_QUIC_TRACE_API_TYPE
in the ETW manifest.[Microsoft-Quic][strm][0xFFFF9F021563E5E0] Reset Reliable ACKed in OnResetReliableAck. Send side. UnAckedOffset=7077, ReliableOffsetSend=5000
, isn't necessary because (1) you log the reliable offset when it's originally set,a nd (2) we already log the unacked offset:[Microsoft-Quic][strm][0xFFFF9F021563E5E0] SF:0 FC:72613 QS:10000 MAX:9890 UNA:7077 NXT:9890 RECOV:0-0
. Perhaps we should just update that second log to include reliable offset (though I'm not sure).Affected OS
Additional OS information
Windows kernel mode
MsQuic version
main
Steps taken to reproduce bug
Run automation.
Expected behavior
All tests pass
Actual outcome
One test doesn't and we also see crashes.
Additional details
No response