[Asterisk-code-review] Core/Stasis: Fix "FRACK!, Failed assertion bad magic number" happens ... (asterisk[16])

Mon May 24 07:42:58 CDT 2021

Evgenios Muratidis has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15762 )

Change subject: Core/Stasis: Fix "FRACK!, Failed assertion bad magic number" happens when unsubscribe an application from an event source
......................................................................

Patch Set 2:

You are not carefully reading the clarification of the changes I have made. Please read the above explanations again.

Note that I did not come up with this approach to managing objects, I only adhere to this rule.

The subscription logic allows you to subscribe not only to one but also to several applications to the same subscription. The only difference is that there are two ways to store objects for later search and retrieval:
1. Vector for technology subscriptions (tech_subscriptions)
2. Special container for resource subscriptions (endpoint_subscriptions)

By analogy with COM, the reference count of an object must be equal to the number of references to that object.
If the object's reference count becomes 0, then the object is self-destructing.
If a function uses RAII_VAR for an object being processed, then the getter or create function must take care of incrementing the object's reference count by 1 when it returns.
Note that calling ao2_link increments the object reference count by 1, while ao2_unlink decrements the object reference count by 1.

Once again, let's briefly consider the situation when we have one subscription, and several applications that "want" to subscribe to this subscription:

App subscription 1:
1. Search for a subscription in the repository. No subscription found. Create new subscription object (link count = 2)
2. Checking whether the application has a current subscription. No subscription found
3. Adding information about the application to the subscription object (sub-> applications)
4. Checking the number of signed applications for a subscription. 1 application signed. Since the link counter of the subscription object will be equal to 1 after exiting the messaging_app_subscribe_endpoint function, there is no need to increase the link counter of the subscription object.
5. Exit the function. RAII_VAR fires. Subscription Object Link Count = 1.
As a result, we have: the number of applications = 1, the counter of reference to the subscription object = 1. That is. 1 application refers to the subscription.

App 2 subscription:
1. Search for a subscription in the repository. Subscription found. Retrieving a subscription object (reference count = 2)
2. Checking whether the application has a current subscription. No subscription found
3. Adding information about the application to the subscription object (sub-> applications)
4. Checking the number of signed applications for a subscription. Signed 2 applications. Since the link counter of the subscription object, after exiting the messaging_app_subscribe_endpoint function, will be equal to 1, and the subscribed applications will be 2, then it is necessary to increase the link counter of the subscription object by 1 (link counter = 3).
5. Exit the function. RAII_VAR fires. Subscription Object Link Count = 2.
As a result, we have, after exiting the function: the number of applications = 2, the counter of reference to the subscription object = 2. That is, the subscription is referenced by 2 applications.

App 3 subscription:
1. Search for a subscription in the repository. Subscription found. Retrieving a subscription object (reference count = 3)
2. Checking whether the application has a current subscription. No subscription found
3. Adding information about the application to the subscription object (sub-> applications)
4. Checking the number of signed applications for a subscription. 3 applications signed. Since the link counter of the subscription object, after exiting the messaging_app_subscribe_endpoint function, will be equal to 2, and the subscribed applications will be 3, then it is necessary to increase the link counter of the subscription object by 1 (link counter = 4).
5. Exit the function. RAII_VAR fires. Subscription Object Link Count = 3.
As a result, we have, after exiting the function: the number of applications = 3, the counter of reference to the subscription object = 3. That is, the subscription is referenced by 3 applications.

Now let's briefly consider the situation when we have one subscription, and several applications that "want" to unsubscribe from this subscription (they were previously subscribed to it):

Unsubscribe application 1:
1. Search for a subscription in the repository. Subscription found. Retrieving a subscription object (reference count = 4)
2. Checking whether the application has a current subscription. Subscription found
3. Removing information about the application from the subscription object (sub-> applications)
4. Checking the number of signed applications for a subscription. Signed 2 applications.
5. Decrease the link count of the subscription object by 1 (link count = 3)
6. Exit the function. RAII_VAR fires. Subscription Object Link Count = 2.
As a result, we have: the number of applications = 2, the counter of reference to the subscription object = 2. That is. the subscription is referenced by 2 applications.

Unsubscribe application 2:
1. Search for a subscription in the repository. Subscription found. Retrieving a subscription object (reference count = 3)
2. Checking whether the application has a current subscription. Subscription found
3. Removing information about the application from the subscription object (sub-> applications)
4. Checking the number of signed applications for a subscription. 1 application signed.
5. Decrease the link count of the subscription object by 1 (link count = 2)
6. Exit the function. RAII_VAR fires. Subscription Object Link Count = 1.
As a result, we have: the number of applications = 1, the counter of reference to the subscription object = 1. That is. 1 application refers to the subscription.

Unsubscribe application 3:
1. Search for a subscription in the repository. Subscription found. Retrieving a subscription object (reference count = 2)
2. Checking whether the application has a current subscription. Subscription found
3. Removing information about the application from the subscription object (sub-> applications)
4. Checking the number of signed applications for a subscription. 0 applications signed. Removing a pointer to a subscription object from storage.
4.1. If the subscription refers to technology subscriptions (tech_subscriptions), then only the pointer is removed from the list of those.
4.2. If the subscription is for resource subscriptions (endpoint_subscriptions), then ao2_unlink is called, which decrements the link count of the subscription object by 1 (ie link count = 1). If you do not increase the counter of reference of the Subscription object back by 1, then the object will already be deleted in paragraph 5, and an exception will be raised in paragraph 6. Therefore, we increase the subscription link count by 1 back (i.e. link count = 2).
5. Decrease the link count of the subscription object by 1 (link count = 1)
6. Exit the function. RAII_VAR fires. Subscription object reference count = 0. Subscription object self-destructs
As a result, we have: the number of applications = 0, the counter of reference to the subscription object = 0. That is. there are no references to the subscription and the subscription object has been destroyed.

-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/15762
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: Ia91b15f8e5ea68f850c66889a6325d9575901729
Gerrit-Change-Number: 15762
Gerrit-PatchSet: 2
Gerrit-Owner: Evgenios Muratidis <jone1984 at hotmail.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua Colp <jcolp at sangoma.com>
Gerrit-Comment-Date: Mon, 24 May 2021 12:42:58 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20210524/22ec720a/attachment-0001.html>