Some doubts about memory leak

[msszzj]

I have a problem. When msquic client handles large traffic, msquic will always apply for memory, and eventually the memory runs out. During this period, the sending efficiency will become lower and lower, and finally become zero. However, if the flow is controlled within the range of a small amount of packet loss, this will not happen. At first, I suspected that there was a memory leak, but if you stop the large flow processing, the memory can be free.

Do you have any suggestions to help me? Thank you.

[nibanks]

and eventually the memory runs out.

Curious. What environment are you running where memory is so limited? I am wondering if our allocation pools are too big/aggressive for your environment.

[msszzj]

We use quicsample as the VPN client (the virtual network card wintun is used, so the traffic is copied to quic once). I use the virtual machine windows, 8g memory. When the memory usage reaches 1.8g, malloc fails and the traffic stops forwarding. I guess that when the performance is insufficient, excessive packet blocking leads to some errors, which affects the sending queue. And I didn't find the mechanism to trigger packet loss when the performance is insufficient in the project. Maybe I didn't read the code carefully enough.

thank

[ThadHouse]

You're running the 32 bit executable. We never run the 32 bit executable, and optimize for 64 bit executables. I wouldn't be super surprised if our caching ends up causing issues. Especially with lots of clients, theres a lot of buffers that need to be held in memory. I'll do some checking to make sure we don't have a 32 bit mode exclusive leak, but can you try 64 bit and see if that still runs into similar issues?

[msszzj]

Thank you for your reply, but I'm sorry, for some special reasons, we can only use 32 bits

[ThadHouse]

If you can only use a 32 bit process, you're going to run into memory issues. Looking at your task manager picture, you're receiving at 422 Mbps. That is going to require draining all streams receive fairly fast. Seeing that CPU utilization is at 100% in the picture as well, you're likely spending a lot of time handling encryption. In a 32 bit process, at that network speed you only have about 40 seconds worth of buffer to spread across all connections. Any missed packet is going to cause the buffer to be held longer. How many connections are you running here?

[ThadHouse]

Oh, I misread your original question, and see this is client. Is the client sending or receiving data?

If its sending, are you using SendBuffering? (Its the default if you don't set any flags on the stream). If so, how are you pacing all your StreamSend calls? MsQuic will accept as much data as you put into StreamSend, even if flow control on the connection won't accept any more data. That will cause the buffers to just build up until you run out of address space a 2GB.

[msszzj]

Thank you for your reply

Through your answer, I seem to have guessed some questions. Now I copy all traffic to quic, and then join the queue through streamsend. I thought streamsend would discard the traffic. I also read the code and saw some protection measures. Please forgive me for not reading the code carefully.

It seems that I need to take some restrictive measures myself. I need to ensure that the traffic is not too large when calling streamsend. Maybe that's what caused the problem.

Thank you very much for your help!!!

[thhous-msft]

The measures we have in the QUIC code are just how much we will buffer internally, and then immediately pass the buffer back to the user using the QUIC_STREAM_EVENT_SEND_COMPLETE event. If you keep passing in buffers past that limit, the buffers will just go onto another queue to be copied to the internal send buffer when more space opens up. StreamSend will never discard traffic, because its supposed to be an ordered reliable stream, and not up to the user to handle discarded data.

[msszzj]

I Understand. Thank you for your reply！！

[msszzj]

First of all, thank you for your help. I have solved the problem by limiting the depth of SendRequestPool.

My idea is that you need to limit the unlimited expansion of SendRequestPool.

Thanks again!!!