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

RE: [reSIProcate] DialogUsageManager.cxx - assert


I think silently dropping the DumFeatureMessage is the correct behavior for
if the chain no longer exists.  We should have a DEBUG or STACK level lock
message.  

Has this problem been reproduced, and does someone have a recipe for it? We
should add something to sanityTests before we make code changes.

--Derek

> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-
> devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Daniel Pocock
> Sent: Friday, May 05, 2006 9:30 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: 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
> >
> >
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel