Subject: Re: [libssh2] #182: Various memory leaks

Re: [libssh2] #182: Various memory leaks

From: libssh2 Trac <trac_at_libssh2.stuge.se>
Date: Mon, 28 Jun 2010 10:32:00 -0000

#182: Various memory leaks
-------------------------------+--------------------------------------------
  Reporter: john@… | Owner: bagder
      Type: defect | Status: assigned
  Priority: normal | Milestone: 1.2.6
 Component: API | Version: 1.2.6
Resolution: | Keywords:
    Blocks: | Blocked By:
-------------------------------+--------------------------------------------

Comment (by john@…):

 Unfortunately I am developing on a Solaris machine, I don't have git and
 don't have any access to the internet from my development machines. I will
 try to see if there is something I can setup.
 For security only certain machines are allowed access to the internet in
 my company.

 As I see it there are 2 basic memory leak issues. They all occur when the
 socket is closed by the remote end, or a network failure occurs.

 1) The '''session''' object does not keep the '''socket_state''' correctly
 in line with the actual state of the socket. This means that a call to
 '''libssh2_channel_free''' is unable to release the memory, as it tries to
 negotiate a shutdown with the server using a dead socket. As shown above
 this can be demonstrated (in ssh2.c) by closing the socket before calling
 '''libssh2_channel_free'''.

 2) If the ssh connection was being negotiated then a call to
 '''libssh2_session_free''' doesn't release all the memory. If you continue
 to call the negotiation function (eg. '''libssh2_session_startup)''' until
 it doesn't return '''LIBSSH2_ERROR_EAGAIN''' then the memory is released.

 With these changes in place I have run my server software and not seen any
 memory leaks (4 hour run 10000 ssh connections). Previously I saw a large
 memory leak (which was my starting point). Due to the way my server
 process is being driven a large number of the ssh sessions fail , the
 remote server rejects the session for various reasons. This tests both the
 dead socket and negotiation failures.

 stuge
 I agree a complete fix will involve a lot of changes. However something
 like the changes I have suggested will need to be made as they involve
 detecting and remembering that the socket is unusable.

 A 0 byte read on a socket indicates that the socket has been closed, see
 here:-
 http://manpages.ubuntu.com/manpages/jaunty/en/man2/recvfrom.2.html
 '''The return value will be 0 when the peer has performed an orderly
 shutdown.'''

 By implementing the changes I have suggested the library becomes much more
 stable, with regard to memory, and may give some breathing space to allow
 for a better fix.

 bagder
 The new function I have suggested '''_libssh2_socket_failed_error''' tests
 to see what errno is, some errors are valid, ie. EINTR is a non fatal
 error for a socket, it just indicates an interrupt has occurred. In most
 cases this can be treated the same as LIBSSH2_ERROR_EAGAIN, except when an
 alarm timer has been setup to fail a read/write/open call.
 When this function returns non zero then the '''socket_state''' is set to
 LIBSSH2_SOCKET_DISCONNECTED.

-- 
Ticket URL: <http://trac.libssh2.org/ticket/182#comment:8>
libssh2 <http://trac.libssh2.org/>
C library for writing portable SSH2 clients
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-06-28