Race conditions in event subscription

[nanang]

Possible scenarios:

1. Subscription timeout vs subscription refresh (thanks Mark Michelson for the report and analysis)
   • A subscription server is established with a subscription timeout of 600 seconds.
   • 600 seconds elapse.
   • Thread B handles an incoming SUBSCRIBE request to refresh the subscription for a further 600 seconds. The UA layer locks the subscription dialog.
   • At the same time, Thread A is tripped because the subscription has timed out. The timer callback is called, and it now is waiting on the dialog lock.
   • Thread B finishes handling the incoming SUBSCRIBE request and schedules a timer entry for 600 seconds from now. In doing so, thread B sets the pjsip_evsub->timer.id to TIMER_TYPE_UAS_TIMEOUT.
   • Thread B releases the dialog lock.
   • Thread A acquires the dialog lock and immediately sets pjsip_evsub->timer.id to TIMER_TYPE_NONE. It calls into the on_server_timeout() callback.
   • on_server_timeout() callback sends a NOTIFY that terminates the subscription. Shortly after, the subscription is destroyed.
   • When the subscription is destroyed, the timer that was previously scheduled is not cancelled because evsub->timer.id is TIMER_TYPE_NONE. At this point, we have a ticking time bomb in the timer heap.
2. Subscription timer callback vs subscription destroy
   • Thread A (worker thread) executing on_timer callback (for any evsub timer operation), waiting for dialog lock.
   • Thread B destroy the subscription, but the destroy procedure fails to cancel the timer as the timer is firing (already removed from timer entry list).
   • Thread A gets the dialog lock and ready to go, but the subscription instance has been destroyed.

[nanang]

In 5177:

Re #1885: Fixed race condition in evsub scenario 1 (Subscription timeout vs subscription refresh).

[nanang]

In 5178:

Re #1885: Fixed race condition in evsub scenario 2 (Subscription timer callback vs subscription destroy).