Opened 3 years ago

Closed 3 years ago

#2802 closed defect (fixed)

memory leak in avformat_find_stream_info

Reported by: sporn Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: leak
Cc: 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 (5)

comment:1 Changed 3 years ago by cehoyos

  • 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 follow-up: Changed 3 years ago by 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?

comment:3 in reply to: ↑ 2 Changed 3 years ago by cehoyos

  • Reproduced by developer set
  • Status changed from new to open

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 ./ffmpeg_g -fflags nobuffer -i tests/lena.pnm
==4039== Memcheck, a memory error detector
==4039== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4039== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4039== 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:11:33 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
==4039== HEAP SUMMARY:
==4039==     in use at exit: 196,748 bytes in 3 blocks
==4039==   total heap usage: 111 allocs, 108 frees, 591,027 bytes allocated
==4039== LEAK SUMMARY:
==4039==    definitely lost: 24 bytes in 1 blocks
==4039==    indirectly lost: 196,724 bytes in 2 blocks
==4039==      possibly lost: 0 bytes in 0 blocks
==4039==    still reachable: 0 bytes in 0 blocks
==4039==         suppressed: 0 bytes in 0 blocks
==4039== Rerun with --leak-check=full to see details of leaked memory
==4039== For counts of detected and suppressed errors, rerun with: -v
==4039== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
Version 0, edited 3 years ago by cehoyos (next)

comment:4 Changed 3 years ago by 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 :)

comment:5 Changed 3 years ago by michael

  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.