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
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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (3)
-
Anthony Minessale
-
hkchoi
-
Ken Rice