[asterisk-dev] Memory leak when use ast_set_read_format

[Mark Michelson]

On 05/25/2010 08:18 AM, MohammedShehzad wrote:
>
> Hi all,
>
> My custom IVR application of asterisk records the voice of user.
> It sets the read format to sleaner using ast_set_read_format funciton 
> on line number  2144.
>         flag = ast_set_read_format(chan, AST_FORMAT_SLINEAR);
> Which is leaving behind some leaks : below is the part of the trace of 
> asterisk under run valgrind as below:
>
> ==11972==
> ==11972== 52,512 bytes in 3 blocks are definitely lost in loss record 
> 115 of 117
> ==11972==    at 0x4A04B32: calloc (vg_replace_malloc.c:279)
> ==11972==    by 0x4A601D: newpvt (utils.h:359)
> ==11972==    by 0x4A714F: ast_translator_build_path (translate.c:288)
> ==11972==    by 0x438270: set_format (channel.c:2778)
> ==11972==    by 0x162A19A8: ??? (app_custom_ivr.c:2144)
> ==11972==    by 0x1629FB83: ??? (app_custom_ivr.c:1099)
> ==11972==    by 0x1629EB25: ??? (app_custom_ivr.c:525)
> ==11972==    by 0x47F21C: pbx_extension_helper (pbx.c:537)
> ==11972==    by 0x4814E0: __ast_pbx_run (pbx.c:2317)
> ==11972==    by 0x482158: pbx_thread (pbx.c:2634)
> ==11972==    by 0x4AB3EB: dummy_start (utils.c:865)
> ==11972==    by 0x376EC06616: start_thread (in 
> /lib64/libpthread-2.5.so <http://libpthread-2.5.so>)
> ==11972==    by 0x376E4D3C2C: clone (in /lib64/libc-2.5.so 
> <http://libc-2.5.so>)
> ==11972==
>
> I do reset the read format back to old read format, but even though it 
> is showing leaks.
>
> Any one can please let me know what i am missing in using 
> ast_set_read_format function?
>
>
> -- 
>
> -MohammedShehzad

ast_set_read_format will allocate memory if it needs to create a 
translation path. However, when you call ast_set_read_format, the old 
translation path on the channel will be freed first. Furthermore, when a 
channel is destroyed, the translation path is freed as well.

When are you seeing this output from valgrind? Are you stopping Asterisk 
with channels still up? if that is the case, then it is not surprising 
to see that there is still memory allocated for translation paths.

Mark Michelson