Bug 1508 - SSLIOP Connector memory leak
Summary: SSLIOP Connector memory leak
Status: RESOLVED FIXED
Alias: None
Product: TAO
Classification: Unclassified
Component: SSLIOP Pluggable Protocol (show other bugs)
Version: 1.3
Hardware: x86 Windows 2000
: P3 normal
Assignee: Ossama Othman
URL:
Depends on:
Blocks:
 
Reported: 2003-05-16 06:19 CDT by david.kinder
Modified: 2003-05-19 13:13 CDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description david.kinder 2003-05-16 06:19:20 CDT
This is a different bug to that which I reported as #1506, though it's seen in 
the same circumstances.

As for #1506, I have a test scenario which involves a client repeatedly 
connecting to CORBA objects incarnated by a server. Each connection leads to 
the server destroying and recreating the CORBA objects it incarnates, so that 
the client is forever creating new SSL connections to new CORBA objects.

After fixing #1506, I find that my client application still leaks a small 
amount of memory every time it creates a new SSL connection. I've tracked the 
bug down to instances of TAO_SSLIOP_Credentials being allocated but never 
deleted. The problem code is in TAO/orbsvcs/orbsvcs/SSLIOP_Connector.cpp, at 
the end of the member function TAO_SSLIOP_Connector::retrieve_credentials():

  else
    {
      // Use the default certificate and private key, i.e. the one set
      // in the SSL_CTX that was used when creating the SSL data
      // structure.
      TAO_SSLIOP_Credentials_ptr c = ssliop_credentials.out ();
      ACE_NEW_THROW_EX (c,
                        TAO_SSLIOP_Credentials (::SSL_get_certificate (ssl),
                                                ::SSL_get_privatekey (ssl)),
                        CORBA::NO_MEMORY ());
      ACE_CHECK_RETURN (TAO_SSLIOP_Credentials::_nil ());
    }
  return ssliop_credentials._retn ();

The intention of this code appears to be to allocate a TAO_SSLIOP_Credentials 
object and to store it in the pointer contained in the ssliop_credentials local 
variable. However, this code cannot work correctly: The pointer is assigned 
only to the local variable c, which means that the object is leaked when c goes 
out of scope.

Looking at this code, I assume that the intention was that c be a reference to 
the pointer in the _var object, not a pointer itself:

      TAO_SSLIOP_Credentials_ptr& c = ssliop_credentials.out ();

Changing this results in the object being returned and the memory leak being 
fixed.

As an aside, the credentials do not appear to be used much, since no-one 
appears to have noticied that the credentials were zero in the default SSLIOP 
case ...

This was all tested with TAO 1.3.0. Looking at the CVS, this problem is present 
in the latest TAO.
Comment 1 Ossama Othman 2003-05-16 14:50:51 CDT
Thanks for the fix David!  The intention was indeed to assign the return value
of the ".out()" call to a reference to TAO_SSLIOP_Credential_ptr since the
".out()" call should not be made within the ACE_NEW_THROW_EX macro since
".out()" would be called another time after the allocation is made for the
!ACE_NEW_THROWS_EXCEPTIONS case, thus negating the allocation.

I'll commit your fix as soon as I get permission from our build czar.  Thanks!
Comment 2 Ossama Othman 2003-05-19 13:11:53 CDT
Fixed.

Mon May 19 11:05:26 2003  Ossama Othman  <ossama@dre.vanderbilt.edu>
...
	From David Kinder <david.kinder@sophos.com>
	* orbsvcs/orbsvcs/SSLIOP/SSLIOP_Connector.cpp (ssliop_connect):

	  The base_connector_.connect() call will increment the handler's
	  reference count once more.  This is not needed as we already
	  hold a reference to the handler.  Therefore we discard this
	  second reference.  Fixes a memory leak.  [Bug 1506]
	  
	  (retrieve_credentials):

	  For the default certificate and private key case, assign the
	  return value of the TAO_SSLIOP_Credentials_var::out() call to a
	  reference to a TAO_SSLIOP_Credentials_ptr.  Previously, the
	  return value was assigned to a local TAO_SSLIOP_Credentials_ptr
	  variable that was lost when leaving the scope of this method.
	  Fixes a memory leak.  [Bug 1508]

Thanks!
Comment 3 Ossama Othman 2003-05-19 13:13:08 CDT
Forgot to hit the "fixed" button.  :-)