memory leak in avformat_find_stream_info

[sporn]

Summary of the bug:
How to reproduce:

call avformat_find_stream_info with AVFMT_FLAG_NOBUFFER set in the formatcontext flags results in a memory leak.

calling it without AVFMT_FLAG_NOBUFFER set (you can safely set it after the call to avformat_find_stream_info) does not leak.

[Carl Eugen Hoyos]

Please provide valgrind output for memory leaks (containing the ffmpeg command line and complete, uncut console output) to make this a valid ticket.

[sporn]

I appreciate that that would help but I'm developing on windows and using c++/CLI in visual studio.

It's already taken me 9 hours to track the leak down to that method call and figure out it was due to the nobuffer flag. Maybe someone that actually has a linux machine with valgrind setup could check it out?

[Carl Eugen Hoyos]

Replying to sporn:

It's already taken me 9 hours to track the leak down to that method call and figure out it was due to the nobuffer flag.

Maybe using valgrind (or Dr.Memory) would have allowed you to save some of the nine hours?

For future tickets: If you believe it is unreasonable to provide all needed information (in this case: valgrind output), please provide at least a command line that allows to reproduce the problem.

$ valgrind --leak-check=full ./ffmpeg_g -fflags nobuffer -i tests/lena.pnm
==26854== Memcheck, a memory error detector
==26854== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==26854== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26854== Command: ./ffmpeg_g -fflags nobuffer -i tests/lena.pnm
==26854==
ffmpeg version N-54868-g9d4dece Copyright (c) 2000-2013 the FFmpeg developers
  built on Jul 22 2013 11:18:28 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 40.100 / 52. 40.100
  libavcodec     55. 18.102 / 55. 18.102
  libavformat    55. 12.102 / 55. 12.102
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 81.102 /  3. 81.102
  libswscale      2.  4.100 /  2.  4.100
  libswresample   0. 17.103 /  0. 17.103
  libpostproc    52.  3.100 / 52.  3.100
Input #0, image2, from 'tests/lena.pnm':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: ppm, rgb24, 256x256, 25 tbr, 25 tbn, 25 tbc
At least one output file must be specified
==26854==
==26854== HEAP SUMMARY:
==26854==     in use at exit: 196,748 bytes in 3 blocks
==26854==   total heap usage: 111 allocs, 108 frees, 591,027 bytes allocated
==26854==
==26854== 196,748 (24 direct, 196,724 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3
==26854==    at 0x4C290FE: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26854==    by 0x4C291A7: posix_memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==26854==    by 0xBFF421: av_mallocz (mem.c:93)
==26854==    by 0xBF3352: av_buffer_realloc (buffer.c:47)
==26854==    by 0x602EED: av_new_packet (avpacket.c:80)
==26854==    by 0x5296B0: img_read_packet (img2dec.c:387)
==26854==    by 0x5C4371: ff_read_packet (utils.c:642)
==26854==    by 0x5C628F: read_frame_internal (utils.c:1294)
==26854==    by 0x5C973D: avformat_find_stream_info (utils.c:2772)
==26854==    by 0x45FE8A: open_input_file (ffmpeg_opt.c:815)
==26854==    by 0x45E9A1: open_files.isra.7 (ffmpeg_opt.c:2495)
==26854==    by 0x465CC8: ffmpeg_parse_options (ffmpeg_opt.c:2532)
==26854==
==26854== LEAK SUMMARY:
==26854==    definitely lost: 24 bytes in 1 blocks
==26854==    indirectly lost: 196,724 bytes in 2 blocks
==26854==      possibly lost: 0 bytes in 0 blocks
==26854==    still reachable: 0 bytes in 0 blocks
==26854==         suppressed: 0 bytes in 0 blocks
==26854==
==26854== For counts of detected and suppressed errors, rerun with: -v
==26854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)

[sporn]

Thanks, I dont ever use command line ffmpeg and the memory tracer i do use (ANTS profiler) only works with managed code hence the 9 hours :)

[Michael Niedermayer]

Fixed in caa7a494817f6f28305b8581cf4f7e8ecf1ae85c

[Bartek Zdanowski]

This is very frustrating that you've closed this ticket. The bug still exists.
Here you go: ffmpeg 4.2.4
I'm reading a jpeg file, when using avformat_find_stream_info() it leaks.
It's used as a library. Not from command line.
Look at valgrind output - same as from 2013!

==991786== 560,253 (24 direct, 560,229 indirect) bytes in 1 blocks are definitely lost in loss record 11 of 11
==991786==    at 0x483E0F0: memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==991786==    by 0x483E212: posix_memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==991786==    by 0x37A642: av_malloc 
==991786==    by 0x37A8FD: av_mallocz 
==991786==    by 0x36FD09: av_buffer_create 
==991786==    by 0x370101: av_buffer_realloc 
==991786==    by 0x167C07: packet_alloc 
==991786==    by 0x167CED: av_new_packet 
==991786==    by 0x15DAC3: ff_img_read_packet 
==991786==    by 0x150C75: ff_read_packet 
==991786==    by 0x15131B: read_frame_internal 
==991786==    by 0x1535BD: avformat_find_stream_info 

[mkver]

1. Can you also test newer versions? Namely versions which contain bae8844e35147f92e612a9e0b44e939a293e5bc9 (i.e. 4.3 or higher)? Because when I look at the code of version 4.2, there is a memleak in case stat() failed ​here.
2. If it is a different issue than the one just mentioned, you will have to provide a small sample program (and sample) to reproduce the issue.

[mkver]

Reopen this (or better: create a new ticket) with the information to reproduce the leak if you still encounter a leak.