[Freeswitch-users] suspecting memory leak about mutex

[Anthony Minessale]

FreeSWITCH uses memory pools, the session has its own pool that is used for
all of its key resources.  The apr objects like mutexes register a destroy
function with the pool when they are created and when you destroy the pool
after the session has ended it cleans up the memory.



On Tue, Jul 23, 2013 at 8:08 AM, Ken Rice <krice at freeswitch.org> wrote:

>
> 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
>
>
> _________________________________________________________________________
> 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
>
>


-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130723/2951dbf4/attachment.html