Opened 14 years ago

Closed 13 years ago

#469 closed defect (remind)

Memory leak when opening h264 file

Reported by: codon1@… Owned by: lorenm@…
Priority: normal Component: libavcodec
Version: unspecified Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

Hi guys,

I have been experimenting with the latest h264 support in CVS and have
discovered a memory leak. Everytime a file is opened, approximately 100 KB is
leaked.

I can reproduce this consistently with any kind of h264 video, either in an avi
or mpg container.

The leak is observable everytime when using valgrind, ie :

$ valgrind --leak-check=yes ffplay /pub/sample_h264_file.mpg

On exit, valgrind will report the leak as follows :

==31842== 19584 bytes in 2 blocks are definitely lost in loss record 46 of 49
==31842== at 0x1B901DF0: memalign (vg_replace_malloc.c:332)
==31842== by 0x1B9C0F97: av_malloc (mem.c:62)
==31842== by 0x1B920ED2: av_find_stream_info (utils.c:1992)
==31842== by 0x804CB49: (within /home/codon/work/ffmpeg/ffplay)
==31842== by 0x1BD62590: SDL_RunThread (in /usr/lib/libSDL-1.2.so.0.7.1)
==31842== by 0x1BD62860: (within /usr/lib/libSDL-1.2.so.0.7.1)
==31842== by 0x1BD99CB3: pthread_start_thread (manager.c:310)
==31842== by 0x1BE9D549: clone (clone.S:119)
==31842==

==31842== 105387 (60998 direct, 44389 indirect) bytes in 1 blocks are definitely
lost in loss record 48 of 49
==31842== at 0x1B901D1D: realloc (vg_replace_malloc.c:306)
==31842== by 0x1BAA8381: ff_combine_frame (parser.c:240)
==31842== by 0x1BB00054: h264_parse (h264.c:7464)
==31842== by 0x1BAA7FB1: av_parser_parse (parser.c:106)
==31842== by 0x1B91C85E: av_read_frame_internal (utils.c:898)
==31842== by 0x804CC45: (within /home/codon/work/ffmpeg/ffplay)
==31842== by 0x1BD62590: SDL_RunThread (in /usr/lib/libSDL-1.2.so.0.7.1)
==31842== by 0x1BD62860: (within /usr/lib/libSDL-1.2.so.0.7.1)
==31842== by 0x1BD99CB3: pthread_start_thread (manager.c:310)
==31842== by 0x1BE9D549: clone (clone.S:119)

I have started and will continue to try to track down the problem myself, as I
know h263dec.c does not suffer from this leak. I am at your disposition to
provide any additional information or media files required.

Thank-you.

Attachments (3)

h264_parse_close.patch (436 bytes) - added by codon1@… 14 years ago.
Patch
h264_parse_close.udiff (501 bytes) - added by codon1@… 14 years ago.
unified diff
h264.c.patch (685 bytes) - added by codon1@… 14 years ago.
New patch to also also free codec extradata

Download all attachments as: .zip

Change History (10)

comment:1 Changed 14 years ago by diego@…

  • Owner changed from diego@… to lorenm@…

Changed 14 years ago by codon1@…

Patch

comment:2 Changed 14 years ago by codon1@…

For the h264 codec, the MpegEncContext? is nested within an H264Context.
Therefore the h264 parser needs a custom ff_parse_close in order to be able to
free the parse context buffer.

I can confirm that valgrind no longer reports the leak with this patch applied.

Changed 14 years ago by codon1@…

unified diff

comment:3 Changed 14 years ago by codon1@…

  • attachments.isobsolete changed from 0 to 1

unified diff of same patch.

comment:4 Changed 14 years ago by codon1@…

Hello,

It has been nearly a month since I have identified this problem, investigated it
and supplied the patch to resolve it.

Any word on when it will be committed to CVS? Should I be doing this myself?
Do you require any additional information?

Thank you.

Changed 14 years ago by codon1@…

New patch to also also free codec extradata

comment:5 Changed 14 years ago by codon1@…

Hello,

I have determined that another leak is still possible if the codec contains
extradata, so I have extended the above patch to resolve this issue as well.

Thanks.

comment:6 Changed 14 years ago by codon1@…

  • attachments.isobsolete changed from 0 to 1

comment:7 Changed 13 years ago by compn

  • Resolution set to remind
  • Status changed from new to closed

patch does not apply anymore

if h264 is still leaking mem, make a report on ffmpeg roundup tracker.

Note: See TracTickets for help on using tickets.