Subject: Re: memory leak in _libssh2_channel_open

Re: memory leak in _libssh2_channel_open

From: Steven Dake <>
Date: Fri, 24 Feb 2012 09:08:11 -0700

On 02/24/2012 08:46 AM, Peter Stuge wrote:
> Hi Steve,
> Steven Dake wrote:
>> I have a long running program which essentially opens a ssh session then
>> periodically runs an exec operation over the session in a new channel.
>> I have implemented it as a non-blocking implementation. I am using 1.4.0.
>> The code seems to work well but I notice there is a bit of a leak found
>> by valgrind:
>> ==6656== at 0x4A074CD: malloc (vg_replace_malloc.c:236)^M
>> ==6656== by 0x4EAC420: _libssh2_transport_read (transport.c:458)^M
>> ==6656== by 0x4EA0694: _libssh2_packet_requirev (packet.c:1219)^M
>> ==6656== by 0x4E97526: _libssh2_channel_open (channel.c:233)^M
>> ==6656== by 0x4E97A8C: libssh2_channel_open_ex (channel.c:352)^M
>> ==6656== by 0x405C9F: assembly_ssh_exec (trans_ssh.c:116)^M
>> ==6656== by 0x4C3754A: job_dispatch (loop_job.c:39)^M
>> ==6656== by 0x4C35FA6: qb_loop_run (loop.c:45)^M
>> ==6656== by 0x4034DB: main (caped.c:163)^M
>> If I run my application for 8 hours, the leak adds up to 300k of memory
>> consumed. I had a look into the code for several hours and don't see an
>> immediate way to fix the problem. I'm not sure even what the problem
>> is, as the channel should free all packets on libssh2_channel_free.
> The leaked memory is the session->payload buffer, which is actually
> never freed by libssh2 at all.


Thanks for responding so quickly,

I'll be happy to try out your patch later today and report results back
sometime this weekend.

> Please see if the attached patch fixes the leak while still allowing
> your program to keep running for a long time. I'm not completely sure
> if the payload would need to be freed explicitly in _session_free()

I had thought along these same lines, but the problem with freeing in
sesson_free is that I don't free my session unless the connection is
determined faulty. I could free and create a new session occasionally
to hack around that, but seems like there should be a better way ;)

> or if there will always be a packet in the packets list refering to
> it. Unsure. It would be helpful if you could test more. If my theory
> is correct then memcheck should still report exactly one packet
> leaked, regardless of running time. Then I will add freeing also to
> _session_free().

one packet leaked is ok (with me), thousands not ok (current codebase).

>> is there a bug in libssh2 here that is known?
> Not known bug. I think most don't have long running sessions.

Well I'm here to help with finding any bugs/leaks/etc with libssh2. I
can even help fix them - I've studied the code base for about 12 hours
so have a reasonable idea of how it operates.

> //Peter
> _______________________________________________
> libssh2-devel

Received on 2012-02-24