We have a memory leak at src/transport.c:474

[timelyslot]

we find libssh2-1.9.0/src/transport.c:474(p->payload = LIBSSH2_ALLOC(session, total_num);), always LIBSSH2_ALLOC without LIBSSH2_FREE it, and memory leak. 
Our program is used for SFTP transmission with 20 threads. Due to the demand, we will not close the session after uploading the file and maintain a long-time connection with the server by keeping it alive. After running for a long time, it is found that libssh2_ sftp_ open_ Ex has a memory leak, and finally locate p - > payload = libsh2_ ALLOC(session, total_ num); We want to know whether there is a wrong method or something wrong

• OS: linux
• libssh2 version 1.10.0

[willco007]

There are a couple places where p->payload is released, the main one is in the function fullpacket. Can you step through your code and make sure it's being hit as expected.

[timelyslot]

Through the test, it is found that when the keepalive is configured with want_reply = 1, the memory leak will occur at the next time which _libssh2_transport_read(libssh2_sftp_open_ex) called. I guess the message from the server is not processed, while allocaing space mistakenly during the next reading. Can you tell us how to deal with this situation

[emiliopastormira]

I see also the same memory leak. In our company we have a single sftp thread, for which we open and close sessions repeatedly.

[emiliopastormira]

Hi,
I could solve the leak as we see it with the following patch

--- a/src/session.c 2021-10-11 15:29:54.768257700 +0100
+++ b/src/session.c 2021-10-13 06:51:50.788974100 +0100
@@ -1053,7 +1053,7 @@
}



/* Free payload buffer */
- if(session->packet.total_num) {
+ if(session->packet.payload) {
    LIBSSH2_FREE(session, session->packet.payload);
  }

As I see it in closing a session, payload would need definitely to be freed, and a pointer should be NOT null, only if in use.

However, I would think that the line may need a change from LIBSSH2_ALLOC to LIBSSH2_REALLOC if that part of the code is going to be used multiple times (as my analysis indicated at first glance)
I could not fully test my second suggestion, sorry.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[cloud4t0r]

I encounter the same memory leak in mly company with version 1.11.0 ...