[asterisk-bugs] [JIRA] (ASTERISK-27121) res_pjsip_mwi: Memory leak on reload

[Sergej (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergej updated ASTERISK-27121:
------------------------------

    Description: 
There seems to be a memory leak around stasis_cache which can be easily replicated with reload of res_pjsip_mwi module. I have tracked it down with REF_DEBUG config option. This is on git version of Asterisk 13 branch (cad74cdd8f). 

My test case includes around 30 PJSIP endpoints with defined mailboxes option. 
The number of endpoints will affect the impact of memory leak due to number of active MWI subscriptions. 

Basically, here is the replicable scenario:
Fetch RSS of Asterisk process
Perform 200 reloads of res_pjsip_mwi
Fetch RSS of Asterisk process again

{noformat}
ps -o rss -p $(pidof -s asterisk)
  RSS
69048

for _ in $(seq 1 200); do asterisk -rx 'module reload res_pjsip_mwi.so' >/dev/null; done

ps -o rss -p $(pidof -s asterisk)
  RSS
90460
{noformat}

By repeating the for loop, RSS of Asterisk process simply grows. 

The problem seems to be around subscribe and unsubscribe message that got cached in stasis_cache. Each subscribe message is cached. However, on unsubscribe message, subscribe message is replaced with unsubscribe message and is never freed as the id of new subscription messages changes. 

I cannot know for sure what is an ideal fix for this, but so far I was able to stop it by doing one of the following: 
1) Do not cache stasis_subscription_change_type() messages in stasis_cache: caching_topic_exec. It seems app_voicemail is reading these messages from cache when starting polling thread, so not sure if this is ideal solution. 
2) On unsubscribe message received in caching_topic_exec, make sure to remove subscription and cleanup the received message
3) Add another stasis_cache_clear_type() message in main/stasis.c for type stasis_subscription_change_type when doing unsubscribe

When such fix is performed RSS does grow a bit, but then it slows down considerably. 
Please note - attached file is for another issue I reported. 

  was:
There seems to be a memory leak around stasis_cache which can be easily replicated with reload of res_pjsip_mwi module. I have tracked it down with REF_DEBUG config option. This is on git version of Asterisk 13 branch (cad74cdd8f). 

My test case includes around 30 PJSIP endpoints with defined mailboxes option. 
The number of endpoints will affect the impact of memory leak due to number of active MWI subscriptions. 

Basically, here is the replicable scenario:
Fetch RSS of Asterisk process
Perform 200 reloads of res_pjsip_mwi
Fetch RSS of Asterisk process again

{noformat}
ps -o rss -p $(pidof -s asterisk)
  RSS
69048

for _ in $(seq 1 200); do asterisk -rx 'module reload res_pjsip_mwi.so' >/dev/null; done

ps -o rss -p $(pidof -s asterisk)
  RSS
90460
{noformat}

By repeating the for loop, RSS of Asterisk process simply grows. 

The problem seems to be around subscribe and unsubscribe message that got cached in stasis_cache. Each subscribe message is cached. However, on unsubscribe message, subscribe message is replaced with unsubscribe message and is never freed as the id of new subscription messages changes. 

I cannot know for sure what is an ideal fix for this, but so far I was able to stop it by doing one of the following: 
1) Do not cache stasis_subscription_change_type() messages in stasis_cache: caching_topic_exec. It seems app_voicemail is reading these messages from cache when starting polling thread, so not sure if this is ideal solution. 
2) On unsubscribe message received in caching_topic_exec, make sure to remove subscription and cleanup the received message
3) Add another stasis_cache_clear_type() message in main/stasis.c for type stasis_subscription_change_type when doing unsubscribe

When such fix is performed RSS does grow a bit, but then it slows down considerably. 


> res_pjsip_mwi: Memory leak on reload
> ------------------------------------
>
>                 Key: ASTERISK-27121
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27121
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.17.0
>            Reporter: Sergej
>         Attachments: chan_iax2_mwi_taskprocessors.diff
>
>
> There seems to be a memory leak around stasis_cache which can be easily replicated with reload of res_pjsip_mwi module. I have tracked it down with REF_DEBUG config option. This is on git version of Asterisk 13 branch (cad74cdd8f). 
> My test case includes around 30 PJSIP endpoints with defined mailboxes option. 
> The number of endpoints will affect the impact of memory leak due to number of active MWI subscriptions. 
> Basically, here is the replicable scenario:
> Fetch RSS of Asterisk process
> Perform 200 reloads of res_pjsip_mwi
> Fetch RSS of Asterisk process again
> {noformat}
> ps -o rss -p $(pidof -s asterisk)
>   RSS
> 69048
> for _ in $(seq 1 200); do asterisk -rx 'module reload res_pjsip_mwi.so' >/dev/null; done
> ps -o rss -p $(pidof -s asterisk)
>   RSS
> 90460
> {noformat}
> By repeating the for loop, RSS of Asterisk process simply grows. 
> The problem seems to be around subscribe and unsubscribe message that got cached in stasis_cache. Each subscribe message is cached. However, on unsubscribe message, subscribe message is replaced with unsubscribe message and is never freed as the id of new subscription messages changes. 
> I cannot know for sure what is an ideal fix for this, but so far I was able to stop it by doing one of the following: 
> 1) Do not cache stasis_subscription_change_type() messages in stasis_cache: caching_topic_exec. It seems app_voicemail is reading these messages from cache when starting polling thread, so not sure if this is ideal solution. 
> 2) On unsubscribe message received in caching_topic_exec, make sure to remove subscription and cleanup the received message
> 3) Add another stasis_cache_clear_type() message in main/stasis.c for type stasis_subscription_change_type when doing unsubscribe
> When such fix is performed RSS does grow a bit, but then it slows down considerably. 
> Please note - attached file is for another issue I reported. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)