We have noticed RSS memory used by Asterisk is growing about 1.3MB per minute, that is about 2GB per day.
Big leak also correlated with unacceptable quality of WAV files recorded with "Monitor".
Valgrind proved it is Opus who is "definitely" leaking, please see the log attached.
We disabled the Opus codec, and Asterisk stopped leaking immediately.
Please fix the leak or advise where to report this bug to.
"definitely" piece of Valgrind log:
==22702== 47,888 bytes in 1 blocks are definitely lost in loss record 6,010 of 6,184
==22702== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22702== by 0x630BEF9: opus_encoder_create (in /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0)
==22702== by 0x274FF88A: opus_encoder_construct (codec_opus.c:100)
==22702== by 0x274FFC31: lintoopus_new (codec_opus.c:162)
==22702== by 0x5E6AF3: newpvt (translate.c:338)
==22702== by 0x5E77ED: generate_computational_cost (translate.c:624)
==22702== by 0x5E92B1: __ast_register_translator (translate.c:1187)
==22702== by 0x275004E8: load_module (codec_opus.c:568)
==22702== by 0x533126: start_resource (loader.c:1021)
==22702== by 0x533AD5: load_resource_list (loader.c:1219)
==22702== by 0x534114: load_modules (loader.c:1372)
==22702== by 0x45BBDD: main (asterisk.c:4654)
==22702==
==22702== 47,888 bytes in 1 blocks are definitely lost in loss record 6,011 of 6,184
==22702== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22702== by 0x630BEF9: opus_encoder_create (in /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0)
==22702== by 0x274FF88A: opus_encoder_construct (codec_opus.c:100)
==22702== by 0x274FFC31: lintoopus_new (codec_opus.c:162)
==22702== by 0x5E6AF3: newpvt (translate.c:338)
==22702== by 0x5E77ED: generate_computational_cost (translate.c:624)
==22702== by 0x5E92B1: __ast_register_translator (translate.c:1187)
==22702== by 0x27500558: load_module (codec_opus.c:572)
==22702== by 0x533126: start_resource (loader.c:1021)
==22702== by 0x533AD5: load_resource_list (loader.c:1219)
==22702== by 0x534114: load_modules (loader.c:1372)
==22702== by 0x45BBDD: main (asterisk.c:4654)
==22702==
==22702== 47,888 bytes in 1 blocks are definitely lost in loss record 6,012 of 6,184
==22702== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22702== by 0x630BEF9: opus_encoder_create (in /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0)
==22702== by 0x274FF88A: opus_encoder_construct (codec_opus.c:100)
==22702== by 0x274FFC31: lintoopus_new (codec_opus.c:162)
==22702== by 0x5E6AF3: newpvt (translate.c:338)
==22702== by 0x5E70C7: ast_translator_build_path (translate.c:486)
==22702== by 0x4B83F0: set_format (channel.c:5480)
==22702== by 0x4B86B6: ast_set_write_format (channel.c:5543)
==22702== by 0x4BB0AB: ast_channel_make_compatible_helper (channel.c:6369)
==22702== by 0x4BB180: ast_channel_make_compatible (channel.c:6388)
==22702== by 0x1E17FA53: simple_bridge_join (bridge_simple.c:61)
==22702== by 0x467D9F: bridge_channel_complete_join (bridge.c:422)
==22702==
==22702== 95,776 bytes in 2 blocks are definitely lost in loss record 6,088 of 6,184
==22702== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22702== by 0x630BEF9: opus_encoder_create (in /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0)
==22702== by 0x274FF88A: opus_encoder_construct (codec_opus.c:100)
==22702== by 0x274FFC31: lintoopus_new (codec_opus.c:162)
==22702== by 0x5E6AF3: newpvt (translate.c:338)
==22702== by 0x5E70C7: ast_translator_build_path (translate.c:486)
==22702== by 0x4B83F0: set_format (channel.c:5480)
==22702== by 0x4B86B6: ast_set_write_format (channel.c:5543)
==22702== by 0x4B74AF: ast_write (channel.c:5115)
==22702== by 0x483254: bridge_channel_handle_write (bridge_channel.c:2247)
==22702== by 0x48383C: bridge_channel_wait (bridge_channel.c:2494)
==22702== by 0x483E42: bridge_channel_internal_join (bridge_channel.c:2628)
==22702==
==22702== 3,735,264 bytes in 78 blocks are definitely lost in loss record 6,183 of 6,184
==22702== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22702== by 0x630BEF9: opus_encoder_create (in /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0)
==22702== by 0x274FF88A: opus_encoder_construct (codec_opus.c:100)
==22702== by 0x274FFC31: lintoopus_new (codec_opus.c:162)
==22702== by 0x5E6AF3: newpvt (translate.c:338)
==22702== by 0x5E70C7: ast_translator_build_path (translate.c:486)
==22702== by 0x4B83F0: set_format (channel.c:5480)
==22702== by 0x4B86F2: ast_set_write_format_from_cap (channel.c:5551)
==22702== by 0x5137DC: ast_openstream_full (file.c:783)
==22702== by 0x51362A: ast_openstream (file.c:742)
==22702== by 0x514311: ast_streamfile (file.c:1097)
==22702== by 0x20E10032: playback_exec (app_playback.c:487)
==22702==
==22702== LEAK SUMMARY:
==22702== definitely lost: 3,974,704 bytes in 83 blocks
We have noticed RSS memory used by Asterisk is growing about 1.3MB per minute, that is about 2GB per day. Big leak also correlated with unacceptable quality of WAV files recorded with "Monitor". Valgrind proved it is Opus who is "definitely" leaking, please see the log attached. We disabled the Opus codec, and Asterisk stopped leaking immediately. Please fix the leak or advise where to report this bug to.
"definitely" piece of Valgrind log: