<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br>this is a perfect example of what you should open a ticket on jira....</div><div><br></div><div><br></div><div><br><div>Ken</div>Sent from my iPad</div><div><br>On Jul 23, 2013, at 6:55, hkchoi <<a href="mailto:linuxsarang@naver.com">linuxsarang@naver.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div style="font-size:10pt; font-family:Gulim;"><p>Hello freeswitch-users, </p><p> </p><p>there is some doubt about memory leak in freeswitch implemetation.</p><p> </p><p>when a channel is created, some mutex are created as below.</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">SWITCH_DECLARE(switch_status_t) switch_channel_alloc(switch_channel_t **channel, switch_call_direction_t direction, switch_memory_pool_t *pool)<br>{<br> switch_assert(pool != NULL);</p><p style="font-size: 10pt;"> if (((*channel) = switch_core_alloc(pool, sizeof(switch_channel_t))) == 0) {<br> return SWITCH_STATUS_MEMERR;<br> }</p><p style="font-size: 10pt;"> switch_event_create_plain(&(*channel)->variables, SWITCH_EVENT_CHANNEL_DATA);</p><p style="font-size: 10pt;"> switch_core_hash_init(&(*channel)->private_hash, pool);<br> switch_queue_create(&(*channel)->dtmf_queue, SWITCH_DTMF_LOG_LEN, pool);<br> switch_queue_create(&(*channel)->dtmf_log_queue, SWITCH_DTMF_LOG_LEN, pool);</p><p style="font-size: 10pt;"> switch_mutex_init(&(*channel)->dtmf_mutex, SWITCH_MUTEX_NESTED, pool);<br> switch_mutex_init(&(*channel)->flag_mutex, SWITCH_MUTEX_NESTED, pool);<br> switch_mutex_init(&(*channel)->state_mutex, SWITCH_MUTEX_NESTED, pool);<br> switch_mutex_init(&(*channel)->thread_mutex, SWITCH_MUTEX_NESTED, pool);<br> switch_mutex_init(&(*channel)->profile_mutex, SWITCH_MUTEX_NESTED, pool);<br> ...</p><p style="font-size: 10pt;">}</p><p> </p><p style="font-size: 10pt;">And, It seems that some memory is newly allocated in switch_mutex_init() by comments in the following code.</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">[ switch_apr.h ]</p><p style="font-size: 10pt;">/**<br> * Create and initialize a mutex that can be used to synchronize threads.<br> * @param lock the memory address where the newly created mutex will be<br> * stored.<br> * @param flags Or'ed value of:<br> * <PRE><br> * SWITCH_THREAD_MUTEX_DEFAULT platform-optimal lock behavior.<br> * SWITCH_THREAD_MUTEX_NESTED enable nested (recursive) locks.<br> * SWITCH_THREAD_MUTEX_UNNESTED disable nested locks (non-recursive).<br> * </PRE><br> * @param pool the pool from which to allocate the mutex.<br> * @warning Be cautious in using SWITCH_THREAD_MUTEX_DEFAULT. While this is the<br> * most optimial mutex based on a given platform's performance charateristics,<br> * it will behave as either a nested or an unnested lock.<br> *<br>*/<br>SWITCH_DECLARE(switch_status_t) switch_mutex_init(switch_mutex_t ** lock, unsigned int flags, switch_memory_pool_t *pool);</p><p style="font-size: 10pt;"><br>/**<br> * Destroy the mutex and free the memory associated with the lock.<br> * @param lock the mutex to destroy.<br> */<br>SWITCH_DECLARE(switch_status_t) switch_mutex_destroy(switch_mutex_t *lock); </p><p style="font-size: 10pt;">but, I can't find any code that is related with destroying mutex.</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">In my opinion, </p><p style="font-size: 10pt;">altough a memory size is very tiny for creating mutex, the leaking memory will be more bigger as times go on.</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">It doesn't need to destory the mutex when a channel is destory?</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">could someone explain about this?</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">Thank you in advance.</p><p style="font-size: 10pt;"> </p><p style="font-size: 10pt;">Regards,</p><p style="font-size: 10pt;">hkchoi</p></div>
<table style="display:none"><tbody><tr><td><img src="http://mail.naver.com/readReceipt/notify/?img=oeFqDHk516mYar%2B5MBiCpzElaA2Za6MXMxtZFxCoKo%2BCpxkSFqpoF6k0MoJoKxJg%2BH%2B0Mouq74lR74lcWNFlbX30WLloWrdQarpZp6kq%2Br0dMr2R%2BBF0bNFgWz0q%2BHK5pNi0pBFX1B3o1VlTb4b%3D.gif" border="0"></td></tr></tbody></table></div></blockquote><blockquote type="cite"><div><span>_________________________________________________________________________</span><br><span>Professional FreeSWITCH Consulting Services:</span><br><span><a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a></span><br><span><a href="http://www.freeswitchsolutions.com">http://www.freeswitchsolutions.com</a></span><br><span></span><br><span>FreeSWITCH-powered IP PBX: The CudaTel Communication Server</span><br><span><a href="http://www.cudatel.com">http://www.cudatel.com</a></span><br><span></span><br><span>Official FreeSWITCH Sites</span><br><span><a href="http://www.freeswitch.org">http://www.freeswitch.org</a></span><br><span><a href="http://wiki.freeswitch.org">http://wiki.freeswitch.org</a></span><br><span><a href="http://www.cluecon.com">http://www.cluecon.com</a></span><br><span></span><br><span>FreeSWITCH-users mailing list</span><br><span><a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a></span><br><span><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a></span><br><span>UNSUBSCRIBE:http://<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users">lists.freeswitch.org/mailman/options/freeswitch-users</a></span><br><span><a href="http://www.freeswitch.org">http://www.freeswitch.org</a></span><br></div></blockquote></body></html>