[Ace-users] tao ssliop memory leaks
Venkat
swara101 at yahoo.com
Mon Dec 3 23:57:21 CST 2007
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
>
> >> 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
> >> > libTAO.so.1.6.1`void
> >> > TAO::Profile_Transport_Resolver::resolve(ACE_Time_Value*)+0xb3
> >> > 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`ACE_Lock*TAO_Default_Resource_Factory::create_cached_connection_lock()> +0x121
> >> > libTAO.so.1.6.1`TAO_Transport::TAO_Transport
> >> > #Nvariant 1(unsigned,TAO_ORB_Core*,unsigned long)+0x196
> >> > libTAO_SSLIOP.so.
> >> > 1.6.1`TAO::SSLIOP::Transport::Transport #Nvariant
> >> > 1(TAO::SSLIOP::Connection_Handler*,TAO_ORB_Core*)+0x4f
>
> ...
>
> read more >>
More information about the Ace-users
mailing list