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