Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#507 closed defect (fixed)

Memory leak in mpegts.c

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

Description

Hello,

I have found that approximately 250 bytes are leaked everytime we open a mpeg2
transport stream.

I have determined that the leaks are caused by not freeing the codec's extradata
in mpegts_read_close.

Thanks.

Attachments (1)

mpegts.c.patched (540 bytes ) - added by codon1@… 18 years ago.
Patch for freeing the codec's extradata on read_close.

Download all attachments as: .zip

Change History (8)

by codon1@…, 18 years ago

Attachment: mpegts.c.patched added

Patch for freeing the codec's extradata on read_close.

comment:1 by codon1@…, 18 years ago

comment:2 by diego@…, 18 years ago

Owner: changed from diego@… to mru@…

comment:3 by mans@…, 18 years ago

Status: newassigned

I'm a bit baffled by this. The MPEGTS demuxer never allocates any extradata,
so there should be none to free as suggested by the patch. Please provide a
test case.

comment:4 by codon1@…, 18 years ago

Hi,

Sorry I haven't gotten back to you earlier. The extradata is allocated by
av_find_stream_info, not the TS demuxer.

I have noticed that this problem is pervasive across neraly all formats. The
only demuxer I have encountered so far that correctly frees the extradata in
read_close is avidec.c.

I can provide more information or sample content if still required.

comment:5 by mans@…, 18 years ago

If memory is allocated by generic code, it should be freed by generic code, not
individual demuxers. A leak is still a leak, of course.

comment:6 by codon1@…, 18 years ago

I agree. av_close_input_file appears to be the appropriate place.

comment:7 by mans@…, 18 years ago

Resolution: fixed
Status: assignedclosed

Fixed the proper way.

Note: See TracTickets for help on using tickets.