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.
>
Peter,
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.
Regards
-steve
>
> //Peter
>
>
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-02-24