Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode

[Joegen E. B. <joe...@gm...>]

Hi Gustavo,

I've been tracking this issue in assembla.  Feel free to create an 
account in the tracker so you could comment on the status of the leak.

http://www.assembla.com/spaces/opensbc/tickets/22

Joegen

Joegen E. Baclor wrote:
> Right!   I've found m_MinSE is not getting deleted in 
> SIPMessage::CleanUp().  Patched this in CVS.
>
> Joegen
>
> Gustavo Curetti wrote:
>   
>> Hi Joegen
>>  
>> The modification doesn't solve the memory issues. I continue searching 
>> for the memory leak. 
>>  
>> A new case is attached and this one appear too when debugging with 
>> Microsot Visual.
>>  
>> Originally, i sent the attached Invite every 250 ms and I set the 
>> timer B and H in 20 ms:
>>  
>> #define SIP_TIMER_B 20
>>  
>> #define SIP_TIMER_H 20
>>  
>> Then I change the code 
>> of B2BUserAgent::Registrar::ProcessUpperRegKeepAlive() 
>> for making easier to  replicate the leak:
>>  
>>  
>> void B2BUserAgent::Registrar::ProcessUpperRegKeepAlive()
>> {
>>   while( !m_UpperRegSync.Wait( 250 ) )
>>   {
>>     OString testRequest =
>>     "INVITE sip:5435155555@192.168.0.5:5060 SIP/2.0\r\nContact: 
>> <sip:4284623@192.168.0.10:5060>\r\nCSeq: 101 INVITE\r\nFrom: 
>> <sip:4284623@192.168.0.10>;tag=5A3745C-2418\r\nTo: 
>> <sip:55555555@192.168.0.206>\r\nVia: SIP/2.0/UDP 
>> 192.168.0.206:5060;branch=z9hG4bK63028de3a6b7743a\r\nVia: SIP/2.0/UDP 
>> 192.168.0.10:5060\r\nRecord-Route: 
>> <sip:192.168.0.206:5060;lr>\r\nAllow: INVITE, OPTIONS, BYE, CANCEL, 
>> ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO\r\nUser-Agent: 
>> Cisco-SIPGateway/IOS-12.x\r\nCall-Id: 
>> 3738EB25-278011DD-B92F90A6-C0EF6BE3@192.168.0.10\r\nMax-Forwards 
>> <mailto:3738EB25-278011DD-B92F90A6-C0EF6BE3@192.168.0.10%5Cr%5CnMax-Forwards>: 
>> 6\r\nExpires: 180\r\nContent-Length: 235\r\ndate: Thu, 22 May 2008 
>> 21:52:32 GMT\r\nsupported: timer\r\nmin-se: 1800\r\ncisco-guid: 
>> 926237238-662704605-3106705574-3236916195\r\nremote-party-id: 
>> <sip:4284623@192.168.0.10>;party=calling;screen=no;privacy=off\r\ntimestamp: 
>> 1211493152\r\nallow-events: telephone-event\r\ncontent-type: 
>> application/sdp\r\n\r\nv=0\r\no=CiscoSystemsSIP-GW-UserAgent 7402 717 
>> IN IP4 192.168.0.10\r\ns=SIP Call\r\nc=IN IP4 192.168.0.10\r\nt=0 
>> 0\r\nm=audio 19298 RTP/AVP 0 19\r\nc=IN IP4 192.168.0.10\r\na=rtpmap:0 
>> PCMU/8000\r\na=rtpmap:19 CN/8000\r\na=ptime:20";
>>     testRequest = ParserTools::LineFeedSanityCheck( testRequest );
>>     SIPMessage * msg = new SIPMessage( testRequest );
>>    
>>     OString addrStr = "192.168.0.147";
>>     OString portStr = "10000";
>>     SIPHeader rcvAddr( "RCVADDR", addrStr );
>>     SIPHeader rcvPort( "RCVPORT", portStr );
>>     SIPHeader rcvTran( "RCVTRAN", "udp" );
>>  
>>     msg->AddInternalHeader( rcvAddr );
>>     msg->AddInternalHeader( rcvPort );
>>     msg->AddInternalHeader( rcvTran );
>>     msg->SetInterfaceAddress( "192.168.0.202" );
>>     msg->SetInterfacePort( 5070 );
>>  
>>     OStringStream traceStream;
>>  
>>     traceStream <<  "<<< "
>>       << msg->GetStartLine() << " "
>>       << " SRC: " << addrStr << ":" << portStr << ":UDP"
>>       << " enc=" << msg->IsEncrypted()
>>       << " bytes=1103";
>>  
>>     OStringStream strPacket;
>>     strPacket << *msg;
>>     COMPOUND_LOG_CONTEXT( LogInfo(), msg->GetCallId(), 
>> traceStream.str(), LogDebugHigh(), strPacket );
>>  
>>     SIPTransport::NotifyRead( traceStream.str() );
>>  
>>     if( msg->IsInvite() )
>>     {
>>       SIPMessage * trying = new SIPMessage();
>>       msg->CreateResponse( *trying, SIPMessage::Code100_Trying );
>>       Via via;
>>       msg->GetViaAt(0, via );
>>       if( via.IsBehindNAT() )
>>       {
>>         SIPURI srcURI;
>>         srcURI.SetHost(addrStr);
>>         srcURI.SetPort(portStr);
>>         trying->SetSendAddress(srcURI);
>>       }
>>       if( msg->IsEncrypted() )
>>         trying->SetEncryption( TRUE );
>>       GetTransportManager()->ProcessOutbound( trying );
>>     }
>>  
>>     GetTransportManager()->OnTransportEvent(
>>     new SIPTransportEvent(
>>       msg,
>>       SIPTransportEvent::UDPPacketArrival
>>     ) );
>>
>>     /*///process the keep alives here
>>     for( PINDEX i = 0; i < GetRegistrationDB().GetSize(); i++ )
>>     {
>>       SIPMessage reg;
>>       if( GetRegistrationDB().GetRegistration( i, reg ) )
>>       {
>>         if( reg.HasInternalHeader( "upper-reg" ) )
>>         {
>>           /// this is an upper reg, send a keep-alive
>>           /// Check the last via if its from a private IP
>>           Via via;
>>           if( reg.GetViaAt( reg.GetViaSize() - 1, via ) )
>>           {
>>             if( via.IsBehindNAT() )
>>             {
>>               SIPURI target;
>>               target.SetHost( via.GetReceiveAddress().AsSTLString() );
>>               target.SetPort( via.GetRPort() );
>>               SIPMessage keepAlive;
>>               RequestLine requestLine;
>>               requestLine.SetMethod( "KEEP-ALIVE" );
>>               requestLine.SetRequestURI( target );
>>               keepAlive.SetStartLine( requestLine );
>>               GetUserAgent().TransportWrite( keepAlive );
>>             }
>>           }
>>         }
>>       }
>>     }*/
>>   }
>> }
>>
>>  
>> The OpenSBC is in "Proxy Only Mode" and the configuration is in 
>> "OpenSBC.reg" (attached).
>>  
>> I compile the OpenSBC in Microsoft Visual C++ 2005 obtaining the exe 
>> attached.
>>  
>> Any idea?
>>  
>> Thanks for your help.
>>  
>> Gustavo
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>     
>>> Date: Thu, 5 Jun 2008 14:18:35 +0800
>>> To: cur...@gm...
>>> Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode
>>> From: joe...@gm...
>>>
>>> Hi Gustavo,
>>>
>>> Yes, i'm able to replicate it. For some reason, the code I #ifdefed in
>>> AppendVia() below is causing it. Let me know if it solves your issues.
>>> I've tried looking at what its doing but nothing is evident as to 
>>>       
>> why it
>>     
>>> would leak. If you find something, let me know
>>>
>>> Joegen
>>>
>>> BOOL SIPMessage::AppendVia(
>>> const Via & header
>>> )
>>> {
>>> GlobalLock();
>>>
>>> ParseViaList();
>>>
>>> if( m_ViaList == NULL )
>>> {
>>> m_ViaList = new Via::Collection();
>>> m_ViaList->Append( new Via( header ) );
>>> }else
>>> {
>>>
>>> #if 0 // For some reason, this sanity check is leaking mem
>>> /// sanity check
>>> if( m_ViaList->GetSize() > 0 )
>>> {
>>> Via & topVia = (*m_ViaList)[0];
>>>
>>> SIPURI topViaURI = topVia.GetURI();
>>>
>>> SIPURI newURI = header.GetURI();
>>>
>>> if( SIPTransport::IsTheSameAddress( topViaURI, newURI, TRUE ) )
>>> return FALSE;
>>> }
>>> #endif
>>>
>>> ///we append it on top
>>> Via::Collection oldViaList = *m_ViaList;
>>> oldViaList.MakeUnique();
>>> delete m_ViaList;
>>>
>>> m_ViaList = new Via::Collection();
>>> m_ViaList->Append( new Via( header ) );
>>>
>>> for( PINDEX i = 0; i < oldViaList.GetSize(); i++ )
>>> m_ViaList->Append( new Via( oldViaList[i] ) );
>>>
>>> m_ViaList->MakeUnique();
>>> }
>>>
>>>
>>> return TRUE;
>>> }
>>>
>>>
>>> Gustavo Curetti wrote:
>>>       
>>>> Hi Joegen
>>>>
>>>> The destructor is called. The problem seem to be the headers like 
>>>>         
>> Via,
>>     
>>>> RecordRoute, Contact, Allow, Supported (List headers).
>>>>
>>>> The leak is very easy to reproduce. I change the code of
>>>> B2BUserAgent::Registrar::ProcessUpperRegKeepAlive:
>>>>
>>>>
>>>> void B2BUserAgent::Registrar::ProcessUpperRegKeepAlive()
>>>> {
>>>> while( !m_UpperRegSync.Wait( 10 ) )
>>>> {
>>>>
>>>> SIPMessage * msg = new SIPMessage();
>>>>
>>>> msg->AppendVia(Via("SIP/2.0/UDP 192.168.0.10:5060"));
>>>> msg->AppendVia(Via("SIP/2.0/UDP
>>>>
>>>>         
>> 192.168.0.206:5060;branch=z9hG4bK440fdc3e04de9d10;rport=5060;received=192.168.0.206"));
>>     
>>>> msg->AppendRecordRoute(RouteURI("<sip:192.168.0.206:5060;lr>"));
>>>> msg->AppendContact(ContactURI("<sip:5435155555@192.168.0.5>"));
>>>> msg->AppendAllow(Allow("INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
>>>> SUBSCRIBE, NOTIFY"));
>>>> msg->AppendSupported(Supported("replaces"));
>>>>
>>>> delete msg;
>>>> }
>>>> }
>>>>
>>>>
>>>> I compile the OpenSBC in Microsoft Visual C++ 2005 obtaining the exe
>>>> attached.
>>>> I execute "OpenSBC Debug" in Windows 2003 or Windows 2000 and the 
>>>>         
>> leak
>>     
>>>> is there.
>>>>
>>>> I put traces and SIPMessage::~SIPMessage(), SIPMessage::Cleanup() are
>>>> called.
>>>>
>>>> Any idea?
>>>>
>>>> Thanks for your help.
>>>>
>>>> Gustavo
>>>>
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>>> Date: Mon, 2 Jun 2008 10:19:08 +0800
>>>>> To: cur...@gm...; 
>>>>>           
>> ope...@li...
>>     
>>>>> From: joe...@gm...
>>>>> Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode
>>>>>
>>>>> Try putting a trace before and after the "delete" statement to 
>>>>>           
>> be sure
>>     
>>>>> that its getting called. From what i see, assuming that SIPMessage
>>>>> destructor performs proper cleanup, that a leak here can only be 
>>>>>           
>> caused
>>     
>>>>> by an exception occurring in the SIPMessage constructor;
>>>>>
>>>>> Gustavo Curetti wrote:
>>>>>           
>>>>>> Hi Joegen:
>>>>>>
>>>>>> The memory leak is hard to find. I send the 200 OK repeatedly but
>>>>>>             
>>>> the memory leak doesn't appear if i'm debugging with Microsot Visual
>>>> 2005, but the leak appears if i'm running the OpenSBC like a service.
>>>>         
>>>>>> If I comment:
>>>>>>
>>>>>>
>>>>>> void SIPStack::EnqueueTransportWriteEvent(
>>>>>> const SIPMessage & message,
>>>>>> SIPTransportEvent::Type eventType
>>>>>> )
>>>>>> {
>>>>>> if( m_IsTerminating )
>>>>>> return;
>>>>>>
>>>>>> /*SIPMessage * msg = new SIPMessage(message);
>>>>>>
>>>>>> msg->SetInternalHeader( "TRN-ID", 
>>>>>>             
>> msg->GetTransactionId().AsString());
>>     
>>>>>> m_TransportManager->EnqueueEvent( new SIPTransportEvent( msg,
>>>>>>             
>>>> eventType ) );*/
>>>>         
>>>>>> }
>>>>>>
>>>>>> there is not leak. But if I modify the code like this:
>>>>>>
>>>>>>
>>>>>> void SIPStack::EnqueueTransportWriteEvent(
>>>>>>             
>>>>>> const SIPMessage & message,
>>>>>> SIPTransportEvent::Type eventType
>>>>>> )
>>>>>> {
>>>>>> if( m_IsTerminating )
>>>>>> return;
>>>>>>
>>>>>> SIPMessage * msg = new SIPMessage(message);
>>>>>>
>>>>>> /*msg->SetInternalHeader( "TRN-ID",
>>>>>>             
>>>> msg->GetTransactionId().AsString());
>>>>         
>>>>>> m_TransportManager->EnqueueEvent( new SIPTransportEvent( msg,
>>>>>>             
>>>> eventType ) );*/
>>>>         
>>>>>> delete msg;
>>>>>> }
>>>>>>
>>>>>> the leak shows up. I don't understand why this happens if I'm
>>>>>>             
>>>> deleting the msg.
>>>>         
>>>>>> What i said in the last mail about CSeq is not seem to be the 
>>>>>>             
>> reason.
>>     
>>>>>> Any idea? Thanks for your help.
>>>>>> Gustavo
>>>>>>
>>>>>>
>>>>>> From: cur...@ho...Subject: RE: [OpenSIPStack]
>>>>>>             
>>>> Memory Leak in Proxy and Full ModeDate: Fri, 30 May 2008 17:04:37 
>>>>         
>> +0200
>>     
>>>>>> Hi Joegen: I found that the memory leak is when you create a
>>>>>>             
>>>> SIPMessage from other SIPMessage or from a OString and then you 
>>>>         
>> delete
>>     
>>>> de message. In the case of the 200 Ok the message is created in:
>>>>
>>>>         
>> ProxySessionManager::OnOrphanedMessage()SIPUserAgent::TransportWrite()SIPStack::EnqueueTransportWriteEvent(){SIPMessage 
>>
>>     
>>>> * msg = new SIPMessage(message); The memory leak is because the CSeq
>>>> header. If i comment : SIPMessage::SIPMessage(const SIPMessage &
>>>> msg)SIPMessage & SIPMessage::operator=(const SIPMessage & msg)void
>>>> SIPMessage::AssignContents(SIPMessage & msg){ /*if( m_CSeq != NULL )
>>>> msg.m_CSeq = static_cast<CSeq*>(m_CSeq->Clone());*/} There is no more
>>>> memory leak. I try to replace: SIPMessage * msg = new
>>>> SIPMessage(message); ----> SIPMessage * msg = new
>>>> SIPMessage(message.AsString()); but the memory leak still exist 
>>>>         
>> unless
>>     
>>>> i comment: void SIPMessage::Finalize(){ /*if( m_CSeq == NULL ) {
>>>> m_CSeq = new CSeq( h ); }*/} That's what i found so far. Gustavo
>>>>         
>>>>>>             
>>>>>>> Date: Fri, 30 May 2008 11:26:11 +0800> To:
>>>>>>>               
>>>> cur...@gm...; ope...@li...>
>>>> Subject: Re: [OpenSIPStack] Memory Leak in Proxy and Full Mode> From:
>>>> joe...@gm...> > Hi Gustavo,> > Take a look at void
>>>> ProxySession::OnFinalResponse( SIPMessage & message > ) method. Can
>>>> you verify if the object created in:> > manager.CreateTuple(
>>>> m_OriginalInvite, m_RoutedInvite, 10 );> > Actually expires after 10
>>>> seconds?> > Putting a breakpoint at
>>>> ProxySessionTupleManager::Tuple::~Tuple() should > be enough to
>>>> confirm it.> > Also by any chance, did you accidentally think that
>>>> this tuple is the > mem leak because it was created after the
>>>> transaction?> > Joegen> > > Gustavo Curetti wrote:> > Hi Joegen> > 
>>>>
>>>> I found a memory leak when the OpenSBC is configured in Proxy or Full
>>>> mode. When i send a 200 Ok for example in B2B mode there is no memory
>>>> leak, but when i send a 200 ok in Proxy or Full mode, some memory is
>>>> taken and never released. I attach the logs. The OpenSBC
>>>> (192.168.0.202:5070) is running under Windows.> > > > Thanks for your
>>>> help> > > > Gustavo> >
>>>> _________________________________________________________________> >
>>>> Ingresá ya a MSN Deportes y enterate de las últimas novedades del
>>>> mundo deportivo.> > http://msn.foxsports.com/fslasc/> >
>>>>
>>>>         
>> ------------------------------------------------------------------------>
>>     
>> -------------------------------------------------------------------------> 
>>
>>     
>>>>> This SF.net email is sponsored by: Microsoft> > Defy all 
>>>>>           
>> challenges.
>>     
>>>> Microsoft(R) Visual Studio 2008.> >
>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> >
>>>>
>>>>         
>> ------------------------------------------------------------------------>
>>     
>>>>>>> _______________________________________________> >
>>>>>>>               
>>>> opensipstack-devel mailing list> >
>>>> ope...@li...> >
>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel> > 
>>>>
>>>>
>>>>         
>> ------------------------------------------------------------------------>
>>     
>>>>>>> No virus found in this incoming message.> > Checked by AVG. > >
>>>>>>>               
>>>> Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date:
>>>> 5/23/2008 3:36 PM> > > >
>>>>         
>>>>>> Ingresá ya a MSN en Concierto y disfrutá los recitales en vivo de
>>>>>>             
>>>> tus artistas favoritos. MSN en Concierto
>>>>         
>>>>>> _________________________________________________________________
>>>>>> Descargá ya gratis y viví la experiencia Windows Live.
>>>>>> http://www.descubrewindowslive.com/latam/index.html
>>>>>>
>>>>>>             
>> -------------------------------------------------------------------------
>>     
>>>>>> This SF.net email is sponsored by: Microsoft
>>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>>> _______________________________________________
>>>>>> opensipstack-devel mailing list
>>>>>> ope...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>
>>>>>
>>>>>           
>> -------------------------------------------------------------------------
>>     
>>>>> This SF.net email is sponsored by: Microsoft
>>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>>> _______________________________________________
>>>>> opensipstack-devel mailing list
>>>>> ope...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>>>>>           
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>> Descargá ya gratis y viví la experiencia Windows Live. Descubre
>>>> Windows Live <http://www.descubrewindowslive.com/latam/index.html>
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>> Internal Virus Database is out-of-date.
>>>> Checked by AVG.
>>>> Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date: 
>>>>         
>> 5/23/2008 3:36 PM
>>     
>>>       
>> ------------------------------------------------------------------------
>> Ingresá ya a MSN Deportes y enterate de las últimas novedades del 
>> mundo deportivo. MSN Deportes <http://msn.foxsports.com/fslasc/>
>> ------------------------------------------------------------------------
>>
>> Internal Virus Database is out-of-date.
>> Checked by AVG. 
>> Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date: 5/23/2008 3:36 PM
>>   
>>     
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
>
>