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