Opened 9 years ago

Closed 9 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 Niedermayer 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 9 years ago.
massif output showing memory leak at libavcodec
massif.out.32533 (401.3 KB ) - added by faham 9 years ago.
massif output - memory leak (ffmpeg revision a61c75e9f77a063cdcf2e68ee752c08a3ff8173d)
memcheck.txt (241.2 KB ) - added by faham 9 years ago.
valgrind memcheck output

Download all attachments as: .zip

Change History (15)

by faham, 9 years ago

Attachment: massif.out.12342 added

massif output showing memory leak at libavcodec

comment:1 by Carl Eugen Hoyos, 9 years ago

Keywords: memory removed
Priority: criticalnormal

Please test current FFmpeg git head and provide valgrind output.

comment:2 by gjdfgh, 9 years ago

Cc: nfxjfg@googlemail.com added

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

comment:3 by faham, 9 years ago

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 by Carl Eugen Hoyos, 9 years ago

Please provide valgrind output for memory leaks.

by faham, 9 years ago

Attachment: massif.out.32533 added

massif output - memory leak (ffmpeg revision a61c75e9f77a063cdcf2e68ee752c08a3ff8173d)

comment:5 by faham, 9 years ago

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 by Carl Eugen Hoyos, 9 years ago

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.

by faham, 9 years ago

Attachment: memcheck.txt added

valgrind memcheck output

comment:7 by faham, 9 years ago

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 by Michael Niedermayer, 9 years ago

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

comment:9 by Michael Niedermayer, 9 years ago

Cc: Michael Niedermayer added

comment:10 by gjdfgh, 9 years ago

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

comment:11 by Hendrik, 9 years ago

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 by Elon Musk, 9 years ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.