Right! I've found m_MinSE is not getting deleted in
SIPMessage::CleanUp(). Patched this in CVS.
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:
\r\nCSeq: 101 INVITE\r\nFrom:
;tag=5A3745C-2418\r\nTo:
\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:
\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
:
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:
;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 << "<<< "
GetStartLine() << " "
<< " SRC: " << addrStr << ":" << portStr << ":UDP"
<< " enc=" IsEncrypted()
<< " bytes=1103";
OStringStream strPacket;
strPacket 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 {
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: curetti dot gustavo at gmail dot com
Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode
From: joegen dot baclor at gmail dot com
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 > 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(""));
msg->AppendContact(ContactURI(""));
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: curetti dot gustavo at gmail dot com;
opensipstack-devel at lists dot sourceforge dot net
From: joegen dot baclor at gmail dot com
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: curetti_gustavo@hotmail.comSubject: 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(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:
curetti dot gustavo at gmail dot com; opensipstack-devel at lists dot sourceforge dot net>
Subject: Re: [OpenSIPStack] Memory Leak in Proxy and Full Mode> From:
joegen dot baclor at gmail dot com> > 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> >
opensipstack-devel at lists dot sourceforge dot net> >
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
opensipstack-devel at lists dot sourceforge dot net
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
opensipstack-devel at lists dot sourceforge dot net
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.
just about anything Open Source.
https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
