Re: [reSIProcate] "opt" builds
I agree that the assert in this case is not necessary - calling end()
when already terminated should just be a no-op. I will remove this
assert.
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Sunitha Beeram
> Sent: Wednesday, September 19, 2007 5:50 PM
> To: David Thompson; Adam Roach
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: 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
> > >
> >
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel