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

Re: [reSIProcate] More problems with `assert'




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@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel