On 02/24/2012 11:18 AM, Peter Stuge wrote:
> Hi!
>
> Steven Dake wrote:
>>>> I tried this patch and it resulted in double free followed by
>>>> segfault from gcc memory checker.
>>>
>>> Does valgrind tell where the packet was previously freed?
>>>
>>> And when does the double free happen?
>>
>> I have attached a gz of the typescript run of valgrind
>>
>> All sorts of bad things happen with that patch (those problems
>> didn't occur prior to patch)
>
> Yes. Looking a little closer the change is too naive. I don't like
> this code at all. :(
>
> Could you revert the patch and find out if the leak is from data
> transfer or from channel create/free?
>
>
The leak seems to occur when a non-blocking channel_open occurs, but
returns EAGAIN (and not all the time). In this case it is transferring
some data, but not enough to close the deal on the open operation. The
data packets stay around and are not freed appropriately. The state
machine of open looks to me as if it should keep these packets around to
finish the non-blocking open operation. I'm not sure if there should be
flushing or freeing of these packets after open finishes. In any case,
when open returns NULL (and the error is set to EAGAIN) there is no
channel to free, although freeing in this way would likely damage the
integrity of the nb open state machine.
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