[reSIProcate] More problems with `assert'

[Daniel Pocock]

Derek MacDonald wrote:

> The assert for line 1166 is complaining that there is a feature 
> message that
> does not have a feature chain.  What is happening is if the
> ServerAuthManager receives an CANCEL it reports that the feature is done,
> even though it has an oustanding auth request. When the UserAuthInfo 
> message
> arrives it triggers the assert as the chain has cleaned itself up.
>
> We can do two things here:
>
> 1. Leave the assert in, and have the contract of features remain that 
> they
> will post stray messages; features cannot call themselves done until they
> have received any outstanding feature messages.
>
> 2. Have dum delete, or call a destroy method, on any DumFeatureMessage 
> that
> does not have a feature chain.
>
> Choice 2 will make  writing features easier, but encourage sloppyness 
> which
> could lead to bugs.  However, if the default implementation of the 
> destroy
> method is assert(0) features that don't want the weak_ptr type behaviour
> will still have the assert.
>
Have either of these options been implemented in the latest trunk?

I've looked at ServerAuthManager.cxx and it returns EventTaken after 
sending the async request for credentials.  Therefore, should the 
DumFeatureChain hang around even if a CANCEL arrives before UserAuthInfo?

>------------------------------------------------------------------------
>
>_______________________________________________
>resiprocate-devel mailing list
>resiprocate-devel at list.sipfoundry.org
>https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>