[Ace-users] tao ssliop memory leaks

Venkat swara101 at yahoo.com
Tue Dec 4 11:26:56 CST 2007


On Dec 3, 11:19 pm, "Johnny Willemsen" <jwillem... at remedy.nl> wrote:
> Hi,
>
> Please store fixes in bugzilla (seehttp://deuce.doc.wustl.edu/bugzilla/index.cgi), then we can integrate them
> when resources are available.
>
> Regards,
>
> Johnny Willemsen
> Remedy IT
> Postbus 101
> 2650 AC  Berkel en Rodenrijs
> The Netherlandswww.theaceorb.nl/www.remedy.nl
>
> *** Integrated compile and test statistics seehttp://scoreboard.theaceorb.nl***
> *** Commercial service and support for ACE/TAO/CIAO             ***
> *** Seehttp://www.theaceorb.nl/en/support.html                ***
>
> "Venkat" <swara... at yahoo.com> wrote in message
>
> <news:06e304b3-895a-41fd-9934-680edf5110cf at e23g2000prf.googlegroups.com>...
>
> > On Dec 3, 7:06 pm, schm... at dre.vanderbilt.edu (Douglas C. Schmidt)
> > wrote:
> > > Hi,
>
> > >         Thanks for the update.  Can you please clarify which version of
> > > TAO you're working with?
>
> > > Thanks,
>
> > >         Doug
>
> > I've got the latest svn head (a week ago).
> > I just checked that I have the latest SSLIOP_Connector.cpp; so the
> > observations are still valid.
>
> > Thanks
> > Venkat
>
> > > >There looks several memory problems with TAO SSLIOP implementation. I
> > > >found at least one bug (that leaks a lot):
>
> > > >  ........removed some code to avoid the clutter...........
>
> > > > if (!ssl_endpoint->credentials_set ())
> > > >  {
>
> > > >      if (this->base_connector_.creation_strategy ()->make_svc_handler
> > > >(
> > > >               svc_handler) != 0)
> > > >        {
> > > >          return 0;
> > > >        }
>
> > > >      ACE_Auto_Basic_Ptr<TAO::SSLIOP::Connection_Handler>
> > > >        safe_handler (svc_handler);
> > > >      TAO::SSLIOP::OwnCredentials_var credentials =
> > > >        this->retrieve_credentials (resolver->stub (),
> > > >                                    svc_handler->peer ().ssl ());
>
> > > >      svc_handler = safe_handler.release ();
> > > >      /// svc_handler is being retained
>
> > > >      ssl_endpoint->set_sec_attrs (qop, trust, credentials.in());
> > > >    }
>
> > > >  // Check the Cache first for connections
> > > >  if (this->orb_core ()->lane_resources ().transport_cache
> > > >().find_transport (
> > > >        desc,
> > > >        transport) == 0)
> > > >    {
>
> > > >    ............. In this block  svc_handler is not released....hence
> > > >memory leak....
> > > >     ....add this line to avoid the memory leaks.....
> > > >        ACE_Auto_Basic_Ptr<TAO::SSLIOP::Connection_Handler>
> > > >            safe_handler (svc_handler);
>
> > > >      // When the transport is not connected wait for completion
> > > >      if (!transport->is_connected())
> > > >        {
> > > >          if (!this->wait_for_connection_completion (resolver,
> > > >                                                     transport,
> > > >                                                     max_wait_time))
> > > >            {
>
> > > >            }
> > > >        }
> > > >    }
>
> > > >Actually, I have an issue with the above implementation. I've an
> > > >application in which client receives a new Object Reference from the
> > > >server. This happens many a million times over the lifetime. Every
> > > >invocation on a new object reference from the client causes the
> > > >execution of the following block:
>
> > > >    if (!ssl_endpoint->credentials_set ()) {
> > > >              .....
> > > >    }
>
> > > >Above memory leak gets exaspareted. I'm wondering about more efficient
> > > >implementation of this block, as it seems merely setting the
> > > >credentials for the end poing of the object reference. Once a
> > > >transport connection is established, the svc_handler gets destroyed.
> > > >It's creation is very expensive. Is there any simple way of setting
> > > >the credentials for an object reference when a transport connection
> > > >that can satisfy the credentials already exist?
>
> > > >Thanks
> > > >Venkat
>
> > > >PS: btw, there seem many other memory problems in the presence of
> > > >connection failures and re-establish. I'm yet to explore this. Any
> > > >ideas that could help?
>
> > > >On Nov 30, 11:51 am, "Johnny Willemsen" <jwillem... at remedy.nl> wrote:
> > > >> Hi,
>
> > > >> Thanks for using the PRF form. We have identified a few weeks ago a
> memory
> > > >> leak in TAO, that has been fixed and will be in the upcoming x.6.2
> version
> > > >> of TAO. Maybe you can try svn head, see ACE-INSTALL.html and the TAO
> > > >> Programmers Guide to acquire that one. Maybe your leaks in SSLIOP are
> the
> > > >> same, maybe they are different.
>
> > > >> Regards,
>
> > > >> Johnny Willemsen
> > > >> Remedy IT
> > > >> Postbus 101
> > > >> 2650 AC  Berkel en Rodenrijs
> > > >> The Netherlandswww.theaceorb.nl/www.remedy.nl
>
> > > >> *** Integrated compile and test statistics
>
> seehttp://scoreboard.theaceorb.nl***> > >> *** Commercial service and support for ACE/TAO/CIAO             ***
> > > >> *** Seehttp://www.theaceorb.nl/en/support.html              ***
>
> > > >> "Venkat" <swara... at yahoo.com> wrote in message
>
> <news:e166681a-7014-48b6-a1ad-074ad11aa1e4 at a39g2000pre.googlegroups.com>...
>
>
>
> > > >> > Hello TAO team,
>
> > > >> >    TAO VERSION: 1.6.1
> > > >> >     ACE VERSION: 5.6.1
>
> > > >> >     HOST MACHINE and OPERATING SYSTEM:
> > > >> >          Solaris 10, i386
>
> > > >> >     TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
> > > >> >     COMPILER NAME AND VERSION (AND PATCHLEVEL):
> > > >> >              Solaris 10, i386
>
> > > >> >     THE $ACE_ROOT/ace/config.h FILE [if you use a link to a
> platform-
> > > >> >     specific file, simply state which one]:
> > > >> >              generation via autoconf
>
> > > >> >     THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if
> you
> > > >> >     use a link to a platform-specific file, simply state which one
> > > >> >     (unless this isn't used in this case, e.g., with Microsoft
> Visual
> > > >> >     C++)]:
> > > >> >           n/a
>
> > > >> >     CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/
> > > >> > default.features
> > > >> >     (used by MPC when you generate your own makefiles):
> > > >> >              ssl
>
> > > >> >     AREA/CLASS/EXAMPLE AFFECTED:
>
> > > >> >     DOES THE PROBLEM AFFECT:
> > > >> >         COMPILATION? no
> > > >> >         LINKING? no
> > > >> >         EXECUTION? Yes
>
> > > >> >     SYNOPSIS:
> > > >> >         Memory leaks in TAO::SSLIOP codebase
>
> > > >> >     DESCRIPTION:
> > > >> >         Client and Server on different nodes with SSLIOP enabled.
> As
> > > >> > Server is processing requests, memory is growing.
>
> > > >> >         I ran memory detector tool, and finding leaks as shown
> below.
> > > >> > Pls. let me know why those are shown as leaks, and what would be
> the
> > > >> > cause?
>
> > > >> > libumem.so.1`umem_cache_alloc_debug+0x12b
> > > >> >                  libumem.so.1`umem_cache_alloc+0xc8
> > > >> >                  libumem.so.1`umem_alloc+0xaf
> > > >> >                  libumem.so.1`malloc+0x2e
> > > >> >                  libCrun.so.1`void*operator new(unsigned long,const
> > > >> > std::nothrow_t&)+0x28
> > > >> > libTAO.so.
>
> 1.6.1`TAO_Wait_Strategy*TAO_Default_Client_Strategy_Factory::create_wait_str> > >> ategy(TAO_Transport*)> +0x2c1
> > > >> >                  libTAO.so.1.6.1`TAO_Transport::TAO_Transport
> > > >> > #Nvariant 1(unsigned,TAO_ORB_Core*,unsigned long)+0x438
> > > >> >                  libTAO_SSLIOP.so.
> > > >> > 1.6.1`TAO::SSLIOP::Transport::Transport #Nvariant
> > > >> > 1(TAO::SSLIOP::Connection_Handler*,TAO_ORB_Core*)+0x4f
> > > >> >                  libTAO_SSLIOP.so.
> > > >> > 1.6.1`TAO::SSLIOP::Connection_Handler::Connection_Handler #Nvariant
> > > >> > 1(TAO_ORB_Core*)+0x1bb
> > > >> >                  libTAO_SSLIOP.so.1.6.1`int
>
> TAO_Connect_Creation_Strategy<TAO::SSLIOP::Connection_Handler>::make_svc_han> > >> dler(TAO::SSLIOP::Connection_Handler*&)> +0x9c
> > > >> >                  libTAO_SSLIOP.so.
>
> 1.6.1`TAO_Transport*TAO::SSLIOP::Connector::ssliop_connect(TAO_SSLIOP_Endpoi> > >> nt*,Security::QOP,const
>
> Security::EstablishTrust&,TAO::Profile_Transport_Resolver*,TAO_Transport_Des> > >> criptor_Interface*,ACE_Time_Value*)> +0x331
> > > >> >                  libTAO_SSLIOP.so.
>
> 1.6.1`TAO_Transport*TAO::SSLIOP::Connector::connect(TAO::Profile_Transport_R> > >> esolver*,TAO_Transport_Descriptor_Interface*,ACE_Time_Value*)> +0x979
>
> > > >> >                  libTAO.so.1.6.1`bool
>
> TAO::Profile_Transport_Resolver::try_connect_i(TAO_Transport_Descriptor_Inte> > >> rface*,ACE_Time_Value*,bool)> +0x278
>
> > > >> >                  libTAO.so.1.6.1`bool
>
> TAO::Profile_Transport_Resolver::try_connect(TAO_Transport_Descriptor_Interf> > >> ace*,ACE_Time_Value*)> +0x32
>
> > > >> >                  libTAO.so.1.6.1`void
>
> TAO_Default_Endpoint_Selector::select_endpoint(TAO::Profile_Transport_Resolv
>
> > > >> er*,ACE_Time_Value*)
>
> > > >> > +0x261
>
> > > >> >      libumem.so.1`umem_cache_alloc_debug+0x12b
> > > >> >                  libumem.so.1`umem_cache_alloc+0xc8
> > > >> >                  libumem.so.1`umem_alloc+0xaf
> > > >> >                  libumem.so.1`malloc+0x2e
> > > >> >                  libCrun.so.1`void*operator new(unsigned long,const
> > > >> > std::nothrow_t&)+0x28
>
> > > >> >                  libTAO_SSLIOP.so.
> > > >> > 1.6.1`ACE_Task<ACE_NULL_SYNCH>::ACE_Task #Nvariant
> > > >> > 1(ACE_Thread_Manager*,ACE_Message_Queue<ACE_NULL_SYNCH>*)+0x127
>
> > > >> >                  libTAO_SSLIOP.so.
>
> 1.6.1`ACE_Svc_Handler<ACE_SSL_SOCK_Stream,ACE_NULL_SYNCH>::ACE_Svc_Handler> > >> > #Nvariant
>
> 1(ACE_Thread_Manager*,ACE_Message_Queue<ACE_NULL_SYNCH>*,ACE_Reactor*)> > >> > +0x5b
> > > >> >                  libTAO_SSLIOP.so.
> > > >> > 1.6.1`TAO::SSLIOP::Connection_Handler::Connection_Handler #Nvariant
> > > >> > 1(TAO_ORB_Core*)+0xa2
> > > >> > libTAO_SSLIOP.so.1.6.1`int
>
> TAO_Connect_Creation_Strategy<TAO::SSLIOP::Connection_Handler>::make_svc_han> > >> dler(TAO::SSLIOP::Connection_Handler*&)> +0x9c
>
> > > >> >                  libTAO_SSLIOP.so.
>
> 1.6.1`TAO_Transport*TAO::SSLIOP::Connector::ssliop_connect(TAO_SSLIOP_Endpoi
>
> > > >> nt*,Security::QOP,const
>
> ...
>
> read more >>

Hi,

  Will file a bug.

I've a question more about the way a (new) object reference end point
is set with a matching transport connection already being available.
Could any one give me ideas to improve. The "overhead" for my
application is pretty high. Before I launch (more effort) quantifying
the time, are there any ideas on my other question?

Thanks
Venkat


More information about the Ace-users mailing list