[reSIProcate] DialogUsageManager.cxx - assert
Daniel Pocock
daniel at readytechnology.co.uk
Fri May 5 11:29:36 CDT 2006
Scott Godin wrote:
>We probably should understand exactly what is causing this first. I
>think only SipMessage's and DumFeatureMessage's get passed into
>incomingProcess. So my guess is that some DumFeatureMessage is
>triggering this (perhaps UserAuthInfo or ChallengInfo?). But if a dum
>feature message is triggering this, then there should already be a
>feature chain created for it (by some previous SipMessage). Can you add
>some debugging and try to figure out what message is triggering this
>assert, and why?
>
>
>
I've cast it to UserAuthInfo with gdb - I'm guessing that the
credentials are being returned late (they are fetched asynchronously
from an SQL database), and that the feature chain may have somehow gone
away, perhaps as a result of a CANCEL or a SIP timeout.
If a DumFeatureMessage does arrive for a feature chain that no longer
exists, should the message be silently dropped, or would some other
behaviour be desirable?
>>-----Original Message-----
>>From: resiprocate-devel-bounces at list.sipfoundry.org
>>
>>
>[mailto:resiprocate-
>
>
>>devel-bounces at list.sipfoundry.org] On Behalf Of Daniel Pocock
>>Sent: Thursday, May 04, 2006 5:48 PM
>>To: resiprocate-devel
>>Subject: [reSIProcate] DialogUsageManager.cxx - assert
>>
>>
>>
>>This section of code (at bottom) in DialogUsageManager is occasionally
>>aborting my application.
>>
>>I entered the core dump with gdb and got the following:
>>
>>(gdb) bt
>>#0 0xb73067a7 in raise () from /lib/tls/libc.so.6
>>#1 0xb73081a9 in abort () from /lib/tls/libc.so.6
>>#2 0xb72ff755 in __assert_fail () from /lib/tls/libc.so.6
>>#3 0xb7e774ad in resip::DialogUsageManager::incomingProcess
>>(this=0x807f050,
>> msg={_M_ptr = 0x80891d0}) at DialogUsageManager.cxx:1104
>>#4 0xb7e771e3 in resip::DialogUsageManager::internalProcess
>>(this=0x807f050,
>> msg={_M_ptr = 0x0}) at DialogUsageManager.cxx:1071
>>
>>(gdb) print msg
>>$1 = {_M_ptr = 0x80891d0}
>>(gdb) print msg._M_ptr
>>$2 = (resip::Message *) 0x80891d0
>>
>>Does anyone have any ideas? Should this be handled more gracefully
>>
>>
>than
>
>
>>calling assert?
>>
>>
>> if (tid != Data::Empty && !mIncomingFeatureList.empty())
>> {
>> FeatureChainMap::iterator it;
>> //efficiently find or create FeatureChain, should prob. be a
>>utility template
>> {
>> FeatureChainMap::iterator lb =
>>mIncomingFeatureChainMap.lower_bound(tid);
>> if (lb != mIncomingFeatureChainMap.end() &&
>>!(mIncomingFeatureChainMap.key_comp()(tid, lb->first)))
>> {
>> it = lb;
>> }
>> else
>> {
>> assert(dynamic_cast<SipMessage*>(msg.get()));
>> it = mIncomingFeatureChainMap.insert(lb,
>>FeatureChainMap::value_type(tid, new DumFeatureChain(*this,
>>mIncomingFeatureList, *mIncomingTarget)));
>> }
>> }
>>
>>_______________________________________________
>>resiprocate-devel mailing list
>>resiprocate-devel at list.sipfoundry.org
>>https://list.sipfoundry.org/mailman/listinfo/resiprocate-deve
>>
>l
>
>
More information about the resiprocate-devel
mailing list