[reSIProcate] Resiprocate crash when rejecting a subscribe that have expires set to 0 with 404

[Scott Godin]

Sounds like we need to fixup this code.  If you have a fix for this, please
feel free to contribute it.

Thanks,
Scott Godin


On Fri, Mar 28, 2014 at 5:47 AM, Ionut Slaveanu <islaveanu at ezuce.com> wrote:

> Hi guys,
>
> The scenario is the following:
> We implemented a resource list server with resiprocate and in
> ServerSubscriptionHandler::onNewSubscription we reject a subscribtion that
> have expires set to 0 to an unexistent resource with 404.
> So in ServerSubscriptionHandler::onNewSubscription we call:
> subscriptionHandle->send(subscriptionHandle->reject(404));
>
> The problem is that ServerSubscription::send calls:
>           if (shouldDestroyAfterSendingFailure(*msg))
> 129│          {
> 130├>            DialogUsage::send(msg);
> 131│             handler->onTerminated(getHandle());
> 132│             delete this;
> 133│             return;
> 134│          }
>
> which deletes the subscriptionHandle. Then ServerSubscription::dispatch
> calls:
>          makeNotifyExpires();
>          handler->onExpiredByClient(getHandle(), msg, *mLastRequest);
>
>          mDialog.makeResponse(*mLastResponse, mLastSubscribe, 200);
>          mLastResponse->header(h_Expires).value() = mExpires;
>          send(mLastResponse);
>
>          send(mLastRequest);  // Send Notify Expires
>
> Currently, resiprocate crashes in makeNotifyExpires, which tries to use
> members from the class which were already deleted.
>
> Is there a way to reject a subscribe that have expires set to 0 with 404?
> Currently the resiprocate code also tries to send the notify when expires
> is set to 0.
>
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140328/70e1cdbe/attachment.htm>