Re: [reSIProcate] "opt" builds
Thanks David. I manage higher level state for my calls
which takes into account the callbacks from resip. So,
when I get an onTerminated() call back, I mark the state
approriately so no more resip calls are made.
>From what I could reconstruct in one case, this was the
sequence of exchange ( btw, I am using the latest resip
version 1.1 ):
1. Remote Server sends us a reInvite ; We send an answer
; we don't get back an ACK for it.
2. In the meantime, the client ends the call, causing
end() to be called on the session; resip returns with a
503 error code:
RESIP:TRANSACTION::TransactionState.cxx:1390:Ran out
of dns entries for 10.0.110.41. Send 503
RESIP:DUM::DialogUsageManager.cxx:1227:Got: SipResp:
503 tid=9efa891343ea7100 cseq=BYE / 2 from(wire)
RESIP:DUM::InviteSession.cxx:1466:InviteSession::dispatch
Terminated SipResp: 503 tid=9efa891343ea7100 cseq=BYE / 2
from(wire)
3. In almost the same second, I see this:
RESIP:DUM::InviteSessionHandler.cxx:25:InviteSessionHandl
er::onAckNotReceived
RESIP:DUM::ClientInviteSession.cxx:174:InviteSession::Ter
minated: end
It looks like this second call to end() was out of my
control ( may be I am holding onto some object longer
than needed here or missing something else..) - the
assertion fires anyway, causing a crash.
So, summarizing my issues:
A) Why is end() being called twice?
A) why is invoking end() twice being treated with an
assertion?
B) I expected assertions to be turned off in the 'opt'
build, so an assertion firing in production env is
unsettling.
Thanks,
~Sunitha
> -----Original Message-----
> From: David Thompson [mailto:mrdatman@xxxxxxxxx]
> Sent: Wednesday, September 19, 2007 1:17 PM
> To: Sunitha Beeram; 'Adam Roach'
> Cc: 'Byron Campen';
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] "opt" builds
>
> Sunitha, I've gotten around accidently calling an end
twice
> by always checking the isTerminated() before I call
end().
>
> David
>
> -----Original Message-----
> From: Sunitha Beeram [mailto:Sunitha.Beeram@xxxxxxxxxx]
> Sent: Wednesday, September 19, 2007 3:00 PM
> To: Adam Roach; David Thompson
> Cc: Byron Campen;
resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] "opt" builds
>
> Hi,
>
> Thanks for all the responses. I agree with the views
> presented here. We had a resip assert earlier that
helped us
> figure out a problem with our usage and it was
definitely helpful.
>
> My follow-up question to my earlier post is this. I
have
> run into a few instances where resiprocate has asserted
here:
> ClientInviteSession.cxx:224:
> Void ClientInviteSession::end(EndReason reason) .....
> .....
> case Terminated:
> assert(0); <=====
> break;
>
>
> To me, this looks like a case where end has been
invoked
> twice ( I have verified my usage of end() and I don't
think
> am calling it twice; this happens when we are handling
a high
> volume of calls and when the server initiated the
disconnect
> - unfortunately I don't have any more traces/logs that
will
> help me understand why this gets triggered so ). In
anycase,
> without understanding much of the state transitions, I
can't
> judge if the
> assert() is called for. Can't resip handle this case
better?
> It just makes me suspicious if asserts are being used
to bail
> out of conditions that can probably still be handled
better....
>
> Any help is understanding why resip is asserting on
line
> 224 will be really great!
>
> Thanks,
> ~Sunitha
>
> > -----Original Message-----
> > From: Adam Roach [mailto:adam@xxxxxxxxxxx]
> > Sent: Wednesday, September 19, 2007 7:16 AM
> > To: David Thompson
> > Cc: 'Byron Campen';
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx;
> > Sunitha Beeram
> > Subject: Re: [reSIProcate] "opt" builds
> >
> > David Thompson wrote:
> > > Thank you for your thoughts and I agree with you.
In
> production we
> > > *shouldn't* ever get to the asserts in the first
> place. In
> > my case, my
> > > program will run into it once every couple of days,
> and with a high
> > > volume of other concurrent calls, I was attempting
to
> not have the
> > > entire program recycle due to the one anomaly (for
> > accounting reasons).
> >
> > Even without the assert()s, though, it's likely to
dump
> core
> > anyway. If the condition enforced by an assert() is
> false,
> > you're probably going to end up dereferencing a null
or
>
> > stepping through a bad pointer in fairly short order.
> >
> > > BTW, am I correct in assuming the OPT build is the
> best for final
> > > production build?
> > >
> >
> > I'm not certain that any thorough characterization of
> the
> > resip stack with regards to compilation options has
> been
> > undertaken recently enough to be relevant. If you're
concerned with
> > getting the most performance out of
> resip, you
> > might want to spend some time tinkering around with
> various
> > compile and link flags and profiling the resultant
> code. You
> > also might consider purchasing Intel's Linux
compiler,
> which
> > is largely gcc compatible and produces somewhat
faster
> code than gcc.
> >
> > <shameless-plug>
> > Alternately, if performance is a primary concern, you
> might
> > check with Estacado Systems, which has a
performance-and-footprint
> > optimized,
> commercially-supported
> > version of the resip stack that runs about 30% faster
> than
> > the publicly-available resip code. See
> > <http://www.estacado.net/SIPBasis.html#foundation>
for
> information.
> >
> > (For full disclosure, I _am_ affiliated with Estacado
> Systems).
> > </shameless-plug>
> >
> > /a
> >
>