A suspected memory leak occurred when the connection was timeout disconnected

[noah-hwang]

The following code appears to have a memory leak.
The scene is as follows:
1.The client initiates a connection and the connection times out，QUIC_CONNECTION_EVENT_SHUTDOWN_COMPLETE event callback.
2.Then actively call ConnectionClose, and DATAPATH_IO_RECV IoType callback, IoResult is EORROR_OPERATION_ABORTED.
3.Final entry CxPlatDataPathSocketProcessReceive, the RecvContext is not release while SocketContext release.
Whether memory leaks are caused by each timeout disconnection.
Thanks!

void
CxPlatDataPathSocketProcessReceive(
    _In_ DATAPATH_RX_IO_BLOCK* IoBlock,
    _In_ uint16_t BytesTransferred,
    _In_ ULONG IoResult
    )
{
    CXPLAT_SOCKET_PROC* SocketProc = IoBlock->SocketProc;

    CXPLAT_DBG_ASSERT(!SocketProc->Freed);
    if (!CxPlatRundownAcquire(&SocketProc->RundownRef)) {
        //
        // Even though we can't process the completion (because the socket is
        // cleaning up) we still need to release the reference it has on the
        // context.
        //
        CxPlatSocketContextRelease(SocketProc);
        return;
    }

[nibanks]

I believe everything should be cleaned up when the socket context and parent socket are cleaned up. Do you have data to show this isn't the case? We run many of our tests with ASAN, and they inform us when we have a leak, and I've never seen one here.

[noah-hwang]

Thank you for your reply!
In the case of server IP address is unreachable, client calls api repeatedly as follow:
ConnectionOpen -> ConnectionStart -> ConnectionClose
But not call ConfigurationClose、RegistrationClose and MsQuicClose.

Visual Studio Performance Profiler monitor show memory growth in CxPlatSocketAllocRecvContext.

This is what I found by adding debug log.
I add static variable count.
Increment in CxPlatSocketAllocRecvContext.
Subtract in CxPlatSocketFreeRecvContext.
Found that RecvContext Alloc but not Free.

[StoicSirius]

I believe I am experiencing the same issue. Repeated calls to ConnectionOpen, ConnectionStart, then ConnectionClose under QUIC_CONNECTION_EVENT_SHUTDOWN_COMPLETE causes process memory to grow larger and larger, usually by about 70 or 150 kilobytes. Doesn't matter if there's a server on the other end or not. Using version 2.4.8 installed with vcpkg.

[StoicSirius]

Ran another test, this time with a barebones connection callback only handling EVENT_SHUTDOWN_COMPLETE (and calling ConnectionClose therein), and repeated calls to ConnectionOpen, then ConnectionShutdown immediately after.
Profiler shows allocations coming from ConnectionOpen, but no frees under ConnectionClose. Is this normal?

[guhetier]

Hi @StoicSirius, since you have a minimal repro, could you please collect logs and open a bug?
What you describe does not seem normal, having logs will help debug it.

https://github.com/microsoft/msquic/blob/main/docs/Diagnostics.md - Using wpr with the "Basic.Verbose" profile should collect detailed traces.

Upgrading to a more recent version might also help. We do not maintain the vcpkg directly as of now, and multiple more recent versions exist.

[StoicSirius]

I tried out v2.5.1 compiled with QuicTLS, and the leaks from my ConnectionOpen -> ConnectionShutdown -> ConnectionClose test were gone. On the other hand, the ConnectionOpen -> ConnectionStart -> Shutdown by transport -> ConnectionClose test still had leaks.

I had some trouble using wpr, but I managed to collect a trace and opened #5329

[guhetier]

Thanks for opening the bug. We will have a look.

Using version 2.4.8 installed with vcpkg

Because you mentioned this - I wanted to mention that we do not officially support the MsQuic vcpkg, so it might be lagging behind / have alterations. If you have a choice, we currently recommend consuming MsQuic through NuGet or git submodules.