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
