[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