[Freeswitch-users] suspecting memory leak about mutex

[Ken Rice]

this is a perfect example of what you should open a ticket on jira....



Ken
Sent from my iPad

On Jul 23, 2013, at 6:55, hkchoi <linuxsarang at naver.com> wrote:

> Hello freeswitch-users, 
> 
>  
> 
> there is some doubt about memory leak in freeswitch implemetation.
> 
>  
> 
> when a channel is created, some mutex are created as below.
> 
>  
> 
> SWITCH_DECLARE(switch_status_t) switch_channel_alloc(switch_channel_t **channel, switch_call_direction_t direction, switch_memory_pool_t *pool)
> {
>     switch_assert(pool != NULL);
> 
>     if (((*channel) = switch_core_alloc(pool, sizeof(switch_channel_t))) == 0) {
>         return SWITCH_STATUS_MEMERR;
>     }
> 
>     switch_event_create_plain(&(*channel)->variables, SWITCH_EVENT_CHANNEL_DATA);
> 
>     switch_core_hash_init(&(*channel)->private_hash, pool);
>     switch_queue_create(&(*channel)->dtmf_queue, SWITCH_DTMF_LOG_LEN, pool);
>     switch_queue_create(&(*channel)->dtmf_log_queue, SWITCH_DTMF_LOG_LEN, pool);
> 
>     switch_mutex_init(&(*channel)->dtmf_mutex, SWITCH_MUTEX_NESTED, pool);
>     switch_mutex_init(&(*channel)->flag_mutex, SWITCH_MUTEX_NESTED, pool);
>     switch_mutex_init(&(*channel)->state_mutex, SWITCH_MUTEX_NESTED, pool);
>     switch_mutex_init(&(*channel)->thread_mutex, SWITCH_MUTEX_NESTED, pool);
>     switch_mutex_init(&(*channel)->profile_mutex, SWITCH_MUTEX_NESTED, pool);
>     ...
> 
> }
> 
>  
> 
> And,  It seems that some memory is newly allocated in switch_mutex_init() by comments in the following code.
> 
>  
> 
> [ switch_apr.h ]
> 
> /**
>  * Create and initialize a mutex that can be used to synchronize threads.
>  * @param lock the memory address where the newly created mutex will be
>  *        stored.
>  * @param flags Or'ed value of:
>  * <PRE>
>  *           SWITCH_THREAD_MUTEX_DEFAULT   platform-optimal lock behavior.
>  *           SWITCH_THREAD_MUTEX_NESTED    enable nested (recursive) locks.
>  *           SWITCH_THREAD_MUTEX_UNNESTED  disable nested locks (non-recursive).
>  * </PRE>
>  * @param pool the pool from which to allocate the mutex.
>  * @warning Be cautious in using SWITCH_THREAD_MUTEX_DEFAULT.  While this is the
>  * most optimial mutex based on a given platform's performance charateristics,
>  * it will behave as either a nested or an unnested lock.
>  *
> */
> SWITCH_DECLARE(switch_status_t) switch_mutex_init(switch_mutex_t ** lock, unsigned int flags, switch_memory_pool_t *pool);
> 
> 
> /**
>  * Destroy the mutex and free the memory associated with the lock.
>  * @param lock the mutex to destroy.
>  */
> SWITCH_DECLARE(switch_status_t) switch_mutex_destroy(switch_mutex_t *lock); 
> 
> but, I can't find any code that is related with destroying mutex.
> 
>  
> 
> In my opinion,
> 
> altough a memory size is very tiny for creating mutex, the leaking memory will be more bigger as times go on.
> 
>  
> 
> It doesn't need to destory the mutex when a channel is destory?
> 
>  
> 
> could someone explain about this?
> 
>  
> 
> Thank you in advance.
> 
>  
> 
> Regards,
> 
> hkchoi
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> 
> 
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130723/1beeb27c/attachment.html