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

Re: [reSIProcate] resiprocate crash or dead lock when first subscribe has expires set to 0


Looking at the dispatch method in ServerSubscription I can see that DUM will send a 200 to the Subscribe request and a Notify with the subscription state as terminated when receiving a Subscribe request with an Expires of 0.  Looks like you trying to do the same thing in the onNewSubscription callback is causing issues.  

I see a couple ways to tackle this:
1.  Use your workaround by not sending a notify in on onNewSubscription if Expires is 0 - knowing that DUM will do it for you.
2.  If you need a body in the notify that goes out in this case - look for Expires of 0 in onNewSubscription and try using update - then doing nothing with the returned message.  I think this will cause the body to go out in the notify message generated by DUM.
3.  We could add a check in the code in dispatch for the Expires = 0 case to check if the application case called accept or sent a notify - then avoid having DUM do it as well.

I don't believe anything has changed since 1.8.11 for this, so this problem would also exist in SVN head.

Regards,
Scott


On Fri, Jan 17, 2014 at 8:19 AM, Ionut Slaveanu <islaveanu@xxxxxxxxx> wrote:
Hi,
We are using resiprocate library 1.8.11-1 from fedora 19 updates to build an rls server.
We have set callbacks for:
-  resip::ServerSubscriptionHandler::onNewSubscription
-  resip::ServerSubscriptionHandler::onTerminated
-  resip::ServerSubscriptionHandler::onExpiredByClient
and so on.

I have noticed that if the first subscribe has expires set to 0 the server enter in a dead lock or even
crashes.
I have investigated this problem and it seems that if in onNewSubscription callback we send
the full notify message after we are sending the 202 message, onTerminated callback is called before onExpiredByClient callback.

The problem is that in ServerSubscription::send is:
       DialogUsage::send(msg);
      if (mSubscriptionState == Terminated)
      {
         handler->onTerminated(getHandle());
         delete this;
      }

So resip::ServerSubscriptionHandle is deleted at this moment and later on, when is passed to
onExpiredByClient callback it dead lock or even crashes the application because it points to invalid memory.

My hack to avoid the crash was to change onNewSubscription callback to not send the notify message if the subscribe had expires set to 0.

Do you know about this problem? Is this fixed in a new resiprocate version?

Thank you!
Ionut




_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel