< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] DialogUsageManager.cxx - assert




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@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-
devel-bounces@xxxxxxxxxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-deve

l