[reSIProcate] More problems with `assert'

[Jason Fischl]

I agree with Scott. If the assert is caused by a bug in the application (or
even by a bug in the higher layers of dum) then we shouldn't just comment it
out. We need to fix it. I suspect that the code compiled with asserts
disabled will continue. So until we have more information, I recommend
leaving the assert in. Any ideas what we would have to do to replicate the
problem in a test? Are these the steps?

1) Send INVITE, get 407
2) request auth info async
3) Send CANCEL before response to requested auth info

Jason



On 11/6/06, Scott Godin <slgodin at icescape.com> wrote:
>
> Well if the problem is caused by b) then the assert is doing its job -
> detecting bugs in the application/stack.  : )
>
> If the assert can be generated by some race condition that is
> unavoidable to applications, then I agree it should be modified to a
> Warning or Error Log.
>
> Scott
>
> > -----Original Message-----
> > From: resiprocate-devel-bounces at list.sipfoundry.org
> > [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
> > Daniel Pocock
> > Sent: Monday, November 06, 2006 9:07 AM
> > To: resiprocate-devel at list.sipfoundry.org
> > Subject: Re: [reSIProcate] More problems with `assert'
> >
> >
> >
> > Scott Godin wrote:
> >
> > >I think it would be good to understand why this is happening first -
> > >this could be a real bug.  Any idea what message type is making here
> > and
> > >why?
> > >
> > >Scott
> > >
> > >
> > >
> > The messages are UserAuthInfo
> >
> > This type of message is more likely to sneak through due to problems
> in
> > the higher level application, although it could be related to dialogs
> > that fail while an asynchronous credential lookup is in progress in
> > another thread.
> >
> > In my case, the stack is in a B2BUA.  The B2BUA processes
> > `requestCredential' in an asynchronous manner, so UserAuthInfo is
> > posted
> > back from a different thread some time after the dialog has commenced.
> >
> > I believe that either of these explanations is possible:
> >
> > a) the caller has sent a CANCEL before the UserAuthInfo message is
> > posted to DUM - for instance, if the RADIUS server is a bit slow,
> > UserAuthInfo might be delayed
> >
> > b) the application, for whatever reason, has posted two copies of the
> > UserAuthInfo message - although I have thoroughly checked for this, it
> > is a possibility and we probably shouldn't crash the whole stack,
> > logging an error should be sufficient
> >
> > >>-----Original Message-----
> > >>From: resiprocate-devel-bounces at list.sipfoundry.org
> > >>[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
> > >>Daniel Pocock
> > >>Sent: Sunday, November 05, 2006 6:37 PM
> > >>To: resiprocate-devel at list.sipfoundry.org
> > >>Subject: [reSIProcate] More problems with `assert'
> > >>
> > >>
> > >>
> > >>I occasionally see this piece of code causing trouble, assert at
> > >>approximately line 1166 of DialogUsageManager.cxx (see code below).
> > >>
> > >>Is it satisfactory to change the `assert' to something less
> > >>catastrophic, like this for example:
> > >>
> > >>#include <typeinfo>
> > >>...
> > >>if(dynamic_cast<SipMessage*>(msg.get()) == 0)
> > >>{
> > >>   ErrorLog(<< "discarding message of type " <<
> > >>typeid(*(msg.get())).name() <<", transaction gone away perhaps?");
> > >>   msg.release();
> > >>   return;
> > >>}
> > >>
> > >>// From DialogUsageManager.cxx:
> > >>
> > >>   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)));
> > >>         }
> > >>      }
> > >>
> > >>      DumFeatureChain::ProcessingResult res =
> > >>it->second->process(msg.get());
> > >>
> > >>_______________________________________________
> > >>resiprocate-devel mailing list
> > >>resiprocate-devel at list.sipfoundry.org
> > >>https://list.sipfoundry.org/mailman/listinfo/resiprocate-deve
> > >>
> > >l
> > >
> > >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.sipfoundry.org
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061106/d262a16a/attachment.htm>