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
