Opened 10 years ago

Closed 22 months ago

#2802 closed defect (fixed)

memory leak in avformat_find_stream_info

Reported by: sporn Owned by:
Priority: normal Component: avformat
Version: 4.2.4 Keywords: leak
Cc: Bartek Zdanowski Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no


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.

Change History (9)

comment:1 by Carl Eugen Hoyos, 10 years ago

Keywords: memory removed

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

comment:2 by sporn, 10 years ago

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?

in reply to:  2 comment:3 by Carl Eugen Hoyos, 10 years ago

Reproduced by developer: set
Status: newopen

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
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== 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== 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/
==26854==    by 0x4C291A7: posix_memalign (in /usr/lib64/valgrind/
==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== 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== For counts of detected and suppressed errors, rerun with: -v
==26854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Last edited 10 years ago by Carl Eugen Hoyos (previous) (diff)

comment:4 by sporn, 10 years ago

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 :)

comment:5 by Michael Niedermayer, 10 years ago

Resolution: fixed
Status: openclosed

comment:6 by Bartek Zdanowski, 2 years ago

Resolution: fixed
Status: closedreopened

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/
==991786==    by 0x483E212: posix_memalign (in /usr/lib/x86_64-linux-gnu/valgrind/
==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 

Last edited 2 years ago by Bartek Zdanowski (previous) (diff)

comment:7 by Bartek Zdanowski, 2 years ago

Cc: Bartek Zdanowski added
Version: git-master4.2.4

comment:8 by mkver, 23 months ago

  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.

comment:9 by mkver, 22 months ago

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.