[reSIProcate] "opt" builds
Adam Roach
adam at nostrum.com
Fri Sep 21 09:40:38 CDT 2007
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 at resiprocate.org [mailto:resiprocate-
>> devel-bounces at resiprocate.org] On Behalf Of Sunitha Beeram
>> Sent: Wednesday, September 19, 2007 5:50 PM
>> To: David Thompson; Adam Roach
>> Cc: resiprocate-devel at list.resiprocate.org
>> 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 at gmail.com]
>>> Sent: Wednesday, September 19, 2007 1:17 PM
>>> To: Sunitha Beeram; 'Adam Roach'
>>> Cc: 'Byron Campen';
>>>
>> resiprocate-devel at list.resiprocate.org
>>
>>> 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 at citrix.com]
>>> Sent: Wednesday, September 19, 2007 3:00 PM
>>> To: Adam Roach; David Thompson
>>> Cc: Byron Campen;
>>>
>> resiprocate-devel at list.resiprocate.org
>>
>>> 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 at nostrum.com]
>>>> Sent: Wednesday, September 19, 2007 7:16 AM
>>>> To: David Thompson
>>>> Cc: 'Byron Campen';
>>>>
>>> resiprocate-devel at list.resiprocate.org;
>>>
>>>> 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 at resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
>
More information about the resiprocate-devel
mailing list