#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-develReceived on 2010-06-28