Re: [reSIProcate] "opt" builds
The only way to call ClientInviteSession::end() twice is if the
InviteSession is still around - perhaps waiting for a BYE response - so
a no-op in this case will be safe.
The assert has already been removed for UAS Invite Sessions, and should
be removed for UAC as well. Previously I think an argument was made
that the application shouldn't be called end() twice, so that assert was
reasonable to leave in, but Sunitha has brought forth a valid scenario,
where DUM itself is the invoking the second call to end().
Scott
> -----Original Message-----
> From: Adam Roach [mailto:adam@xxxxxxxxxxx]
> Sent: Friday, September 21, 2007 10:41 AM
> To: Scott Godin
> Cc: Sunitha Beeram; David Thompson; resiprocate-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] "opt" builds
>
> I could be confused, but I think the last time I tracked this down, I
> decided that the assert was there basically to say, "Hey! You
shouldn't
> have a pointer to this object any more! You don't own it, and need to
> assume that the stack might have already deleted it!"
>
> But I'm not sure about that (and, unfortunately, I don't have time to
> read through the code again at the moment).
>
> So, I guess what I'm saying is: make sure this isn't trying to warn
> about an exceptional condition that might cause a core dump in a race
> situation.
>
> /a
>
> On 9/21/07 9:34 AM, Scott Godin wrote:
> > 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
> >>
> >
> >
>