Opened 4 years ago

Closed 4 years ago

#4484 closed defect (invalid)

libavcodec: memory leak at libavcodec/utils.c:unrefcount_frame

Reported by: faham Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: leak
Cc: nfxjfg@googlemail.com, michael Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I'm using ffmpeg (revision: ecafde6606a51c285ed7ca4d27697392b493919e) to playback HD audio (ac3) contents for more than a few hours (long-term runs) and observe a mem leak in ffmpeg/libavcodec/utils.c:2287 inside unrefcount_frame.

It looks like the call to av_frame_copy_props() is leading to the leak, I'm not sure if it is necessary to do this operation or not but by removing that line the mem leak goes away. Can find further info in the attached valgrind-massif output.

Attachments (3)

massif.out.12342 (348.9 KB) - added by faham 4 years ago.
massif output showing memory leak at libavcodec
massif.out.32533 (401.3 KB) - added by faham 4 years ago.
massif output - memory leak (ffmpeg revision a61c75e9f77a063cdcf2e68ee752c08a3ff8173d)
memcheck.txt (241.2 KB) - added by faham 4 years ago.
valgrind memcheck output

Download all attachments as: .zip

Change History (15)

Changed 4 years ago by faham

massif output showing memory leak at libavcodec

comment:1 Changed 4 years ago by cehoyos

  • Keywords memory removed
  • Priority changed from critical to normal

Please test current FFmpeg git head and provide valgrind output.

comment:2 Changed 4 years ago by gjdfgh

  • Cc nfxjfg@googlemail.com added

You're most likely just using the API incorrectly (which is easy).

comment:3 Changed 4 years ago by faham

Just switched to tip of the master (a61c75e9f77a063cdcf2e68ee752c08a3ff8173d) and the leak is still happening, I'm actually using ffmpeg through gstreamer, gst-libav used libav as a submodule, I've replaced that submodule with ffmpeg (as far as both provide same interfacing functions) and am using the following gstreamer pipeline to playback:

gst-launch-1.0 \
    udpsrc address=239.6.60.1 port=6100 name=udpsrc1 ! \
    queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_tsdemux_1 ! \
    tsdemux name=dmx \
    dmx. ! mpegvideoparse ! \
        queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_videoparse_1 ! \
        vaapidecode name=vaapidecode_1 !  \
        queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_videosink_1 ! \
        vaapisink display=x11 \
    dmx. ! identity ! ac3parse ! avdec_ac3 ! audioconvert ! \
        audioresample sinc-filter-mode=full quality=3 ! \
        audio/x-raw, format=S16LE, rate=44000 ! \
        queue max-size-bytes=0 max-size-buffers=0 max-size-time=10000000000 name=q_audiosink ! \
        autoaudiosink

in this pipeline the avdec_ac3 element utilizes libavcodec of ffmpeg which leads to the memory leak

comment:4 Changed 4 years ago by cehoyos

Please provide valgrind output for memory leaks.

Changed 4 years ago by faham

massif output - memory leak (ffmpeg revision a61c75e9f77a063cdcf2e68ee752c08a3ff8173d)

comment:5 Changed 4 years ago by faham

https://trac.ffmpeg.org/attachment/ticket/4484/massif.out.32533

The updated valgrind massif output is attached. av_malloc is constantly increasing over time at the same spot in libavcodec (can see it with massif-visualizer)

comment:6 Changed 4 years ago by cehoyos

If you want to report a memory leak, valgrind output (and only valgrind output) is needed.
If you don't want to report a memory leak, please explain clearly that you don't want to report a memory leak.
Please understand that "memory leak" is a well defined term and massif (which is a useful tool) is not able to detect memory leaks.

Changed 4 years ago by faham

valgrind memcheck output

comment:7 Changed 4 years ago by faham

https://trac.ffmpeg.org/attachment/ticket/4484/memcheck.txt

valgrind memcheck output is attached to the bug, I generated that with the following command, also stripped out rest of my gstreamer pipeline to make it more easily observable.

valgrind --tool=memcheck --leak-check=full --log-file=memcheck.txt \ 
  ~/gst/master/gstreamer/tools/.libs/gst-launch-1.0 \
  udpsrc address=224.1.1.1 port=5000 ! queue ! \
  tsdemux name=dmx1 \
  dmx1. ! identity ! ac3parse ! avdec_ac3 mode=stereo ! audioconvert ! \
  audioresample sinc-filter-mode=full quality=3 ! \
  audio/x-raw, format=S16LE, rate=44000 ! autoaudiosink

comment:8 Changed 4 years ago by michael

You can probably fix that issue by calling av_frame_unref() on the frame once you are done with using it.

comment:9 Changed 4 years ago by michael

  • Cc michael added

comment:10 Changed 4 years ago by gjdfgh

Apparently he isn't use refcounting (or unrefcount_frame wouldn't be called), so that's not going to help?

comment:11 Changed 4 years ago by heleppkes

gst-ffmpeg did use the API wrong, they used a AVFrame on the stack and never called a free function on it. They changed it end of last month, though, so this can be considered resolved (or invalid, if you want)

comment:12 Changed 4 years ago by richardpl

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