<br><br><div class="gmail_quote">On Wed, Jan 6, 2010 at 8:15 PM, Russell Bryant <span dir="ltr"><<a href="mailto:russell@digium.com">russell@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 01/06/2010 01:36 AM, MohammedShehzad wrote:<br>
> I made the thread detachable by replacing ast_pthread_create_background with<br>
> below code:<br>
> pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);<br>
> ast_pthread_create(&rtp->thread_var,&attr,<br>
> ast_rtp_write_thread, rtp);<br>
><br>
> It resolved the above leak, it seems that there is another leak too as<br>
> below, which did not get resolved:<br>
><br>
> ==3112== 1,241,886 bytes in 2,849 blocks are still reachable in loss record<br>
> 41 of 41<br>
> ==3112== at 0x4005525: malloc (vg_replace_malloc.c:149)<br>
> ==3112== by 0x8075B0A: __ast_alloc_region (astmm.c:115)<br>
> ==3112== by 0x8075AC5: __ast_calloc (astmm.c:198)<br>
> ==3112== by 0x8120CFB: ast_threadstorage_get (threadstorage.h:130)<br>
> ==3112== by 0x8121961: ast_store_lock_info (utils.c:551)<br>
> ==3112== by 0x806BA56: __ast_pthread_mutex_lock (lock.h:369)<br>
> ==3112== by 0x806B97C: ast_register_file_version (asterisk.c:281)<br>
> ==3112== by 0x812091D: __register_file_version (utils.c:28)<br>
> ==3112== by 0x814426A: (within /usr/sbin/asterisk)<br>
> ==3112== by 0x8057A6C: (within /usr/sbin/asterisk)<br>
> ==3112== by 0x8144138: __libc_csu_init (in /usr/sbin/asterisk)<br>
> ==3112== by 0xB2D330: (below main) (in /lib/<a href="http://libc-2.7.so" target="_blank">libc-2.7.so</a>)<br>
> ==3112==<br>
<br>
</div>Are you positive that the thread is actually exiting? If the thread<br>
just does an invite loop, the thread is not going to actually exit, and<br>
the thread local storage will not be destroyed (which is the leak you see).<br>
<br></blockquote></div><br>Thread just exit when the function ast_rtp_stop is executed, also it does not use any memory allocation like malloc, calloc.<br><br>--MohammedShehzad<br><br>