Re: [reSIProcate] More problems with `assert'
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@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Daniel Pocock
> Sent: Monday, November 06, 2006 9:07 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> >>[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> >>Daniel Pocock
> >>Sent: Sunday, November 05, 2006 6:37 PM
> >>To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> >>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@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
>