On Sat, Dec 5, 2015 at 1:40 PM, Clément Bœsch <u...@pkh.me> wrote: > On Sat, Dec 05, 2015 at 01:20:40PM -0500, Ganesh Ajjanagadde wrote: > [...] >> >> + >> >> + AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts); >> >> + if (!fmts_list) >> >> + return AVERROR(ENOMEM); >> >> + return ff_set_common_formats(ctx, fmts_list); >> >> still leaky - when fmts_list is allocated correctly, and >> ff_set_common_formats fails. Proof: use the patch used for the proof >> regarding af_agate. >> >> @Clement: found this while examining avfilter/vf_curves. Can you >> please do the needful there? >> > > i lost track of what's happening here, but isn't ff_set_common_formats() > freeing the list in case of failure?
Unfortunately not, it only unref's and does not free: ==25616== 40 bytes in 1 blocks are indirectly lost in loss record 7 of 14 ==25616== at 0x4C2AD45: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25616== by 0x4C2AE0D: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25616== by 0x77978C6: av_malloc (mem.c:97) ==25616== by 0x50DF1D7: av_malloc_array (mem.h:97) ==25616== by 0x50DF1D7: ff_make_format_list (formats.c:285) ==25616== by 0x511770F: query_formats (vf_curves.c:469) ==25616== by 0x50D33F5: filter_query_formats (avfiltergraph.c:307) ==25616== by 0x50D3BEB: query_formats (avfiltergraph.c:435) ==25616== by 0x50D48C2: graph_config_formats (avfiltergraph.c:1139) ==25616== by 0x50D48C2: avfilter_graph_config (avfiltergraph.c:1250) ==25616== by 0x419424: configure_filtergraph (ffmpeg_filter.c:1042) ==25616== by 0x423072: transcode_init (ffmpeg.c:3035) ==25616== by 0x424895: transcode (ffmpeg.c:4092) ==25616== by 0x407B53: main (ffmpeg.c:4314) > > That pattern is likely used in many places. In that case a more sustainable solution may be useful. I don't know and have no opinions on whether anything useful can be done in formats.c/formats.h for helping here. @Nicolas: any ideas? One can argue that we do not need to address these leaks as they are mostly "theoretical", but I personally am strongly against it unless someone convinces me otherwise. > > -- > Clément B. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
