On 02/24/2012 04:20 PM, Steven Dake wrote:
> On 02/24/2012 04:18 PM, Daniel Stenberg wrote:
>> On Fri, 24 Feb 2012, Steven Dake wrote:
>>>> I'm curious if the leak remains if your app exits? I mean, could it
>>>> be packets that are received and are just appended in the incoming
>>>> package queue and then are never discarded from there?
>>> If my app exits, libssh2 is no longer being consumed by my application
>>> and the leak is collected by the operating system.
>> Sure, but valgrind would still helpfully point out the memory areas that
>> weren't freed by libssh2 and thus were leaks. If they _were_ freed by
>> libssh2 on exit, they were data lingering in some list. Still a leak of
>> some sorts, but it would help us understand what happens.
> Yes I understand now - I'll add a signal handler and correctly free data
> on exit and report back.
After adding the sigint handler, letting my app run for 12 hours, then
ctrl-c the app inside valgrind, the leaks are collected by the sigint
My sigint handler frees any open channels at the time via
libssh2_channel_free() and frees any open sessions| via
libssh2_session_free(). There are some other key gen releated 1-3 block
leaks which don't concern me (and I am probably not cleaning up ssh
So it appears the packets are still present on the session list but
somehow dropped by the open call and not removed.
If you have other suggestions for getting to the root cause please let
me know. I am happy to help.
>>>> 300K during 8 hours seems like a fairly small amount of memory per
>>> yes data per packet seems small but adds up over time
>> Oh indeed. I'm not making up excuses, I'm just trying to make
>> observations to figure out patterns of when it happens.
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-02-25