[FFmpeg-devel] [PATCH] avfilter: add panorama filter

[Ganesh Ajjanagadde]

On Sat, Dec 5, 2015 at 1:40 PM, Clément Bœsch <u at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>