[FFmpeg-devel] [PATCH] mpegtsenc: fix free of adts when not using AAC
Chris Kennedy
bitbytebit at gmail.com
Wed Oct 19 07:12:25 CEST 2011
On Tue, Oct 18, 2011 at 8:05 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> On Wed, Oct 12, 2011 at 09:59:44PM -0500, Chris Kennedy wrote:
> > On Wed, Oct 12, 2011 at 10:18:22PM +0000, Carl Eugen Hoyos wrote:
> > > Chris Kennedy <bitbytebit <at> gmail.com> writes:
> > >
> > > > There is a free for the adts data in writing the trailer onto mpegts
> > > > files, yet it is only allocated when we are using AAC. I have seen
> > > > backtraces that point to this as the issue, although it oddly only
> > > > segfaults on a very rare occasion.
> > >
> > > Please upload the sample that triggers the segfault for you.
> >
> > It's actually from a live stream from a clearQAM mpegts broadcast,
> > so unfortunately has been impossible to get a file that triggers it.
> > It's rare, once every week, and when it happens backtraces always
> > point into libavformat somewhere from either the write trailer
> > function or read frame function. Here's the two backtraces I've
> > gotten, always seems to be when closing an output context and opening
> > a new one for mpegts.
>
> if you cannot upload a sample then maybe running the stuff under
> valgrind might point more clearly to the cause
>
>
This is what it does under valgrind: This is the write frame one that
happens, reading clearQAM HD signals over udp and from clearQAM cards.
There's also a av_read_frame issue too that seems to be either the mpegts
parser doing something odd or somehow the input context streams changing.
Often times from what I can tell basically when the stream is very
'corrupted' then these cause the input context to get confused (thinking the
audio codec or settings suddenly change, they don't, and new streams keep
appearing). Then output wise as below, it seems suddenly the packet buffer
has some frames possibly that have a fully negative large stream index value
and those cause a crash from trying to reference a stream with them as the
index. So just seems like the whole internal system is being somewhat
thrashed by the mpegts packets, admittedly from a probably bad input
clearQAM signal.
[176](0) Closing muxer
[176] 000.00:42:23 w=22.33 a=2[mpegts @ 0x6465080] Dropped corrupted packet
(stream = 0)
==27654== Invalid write of size 2
==27654== at 0x4C2846D: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653)
==27654== by 0x48FF02: mpegts_write_packet (mpegtsenc.c:1041)
==27654== by 0x4D1A07: av_interleaved_write_frame (utils.c:3363)
==27654== by 0x439E8E: main (slicer.c:1333)
==27654== Address 0x6535988 is 0 bytes after a block of size 2,984 alloc'd
==27654== at 0x4C249B8: memalign (vg_replace_malloc.c:581)
==27654== by 0x4C24A67: posix_memalign (vg_replace_malloc.c:709)
==27654== by 0x93E211: av_mallocz (mem.c:90)
==27654== by 0x48E3A0: mpegts_write_header (mpegtsenc.c:510)
==27654== by 0x4D0E30: avformat_write_header (utils.c:3091)
==27654== by 0x43B7C2: open_file (slicer.c:1702)
==27654== by 0x43C17C: start_mux (slicer.c:1895)
==27654== by 0x439140: main (slicer.c:1159)
==27654==
==27654== Invalid read of size 1
==27654== at 0x4C284F1: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653)
==27654== by 0x48F203: mpegts_write_pes (mpegtsenc.c:936)
==27654== by 0x48FF9F: mpegts_write_packet (mpegtsenc.c:1029)
==27654== by 0x4D1A07: av_interleaved_write_frame (utils.c:3363)
==27654== by 0x439E8E: main (slicer.c:1333)
==27654== Address 0x6535a0b is not stack'd, malloc'd or (recently) free'd
==27654==
==27654== Invalid read of size 8
==27654== at 0x4C28518: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653)
==27654== by 0x48F203: mpegts_write_pes (mpegtsenc.c:936)
==27654== by 0x48FF9F: mpegts_write_packet (mpegtsenc.c:1029)
==27654== by 0x4D1A07: av_interleaved_write_frame (utils.c:3363)
==27654== by 0x439E8E: main (slicer.c:1333)
==27654== Address 0x6535a00 is not stack'd, malloc'd or (recently) free'd
==27654==
==27654== Invalid read of size 8
==27654== at 0x4C2852A: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:653)
==27654== by 0x48F203: mpegts_write_pes (mpegtsenc.c:936)
==27654== by 0x48FF9F: mpegts_write_packet (mpegtsenc.c:1029)
==27654== by 0x4D1A07: av_interleaved_write_frame (utils.c:3363)
==27654== by 0x439E8E: main (slicer.c:1333)
==27654== Address 0x65359f0 is not stack'd, malloc'd or (recently) free'd
==27654==
[176] 000.00:42:23--27654-- VALGRIND INTERNAL ERROR: Valgrind received a
signal 11 (SIGSEGV) - exiting
--27654-- si_code=80; Faulting address: 0x0; sp: 0x406af8d60
valgrind: the 'impossible' happened:
Killed by fatal signal
==27654== at 0x38055232: mkFreeBlock (m_mallocfree.c:244)
==27654== by 0x38055CB0: vgPlain_arena_malloc (m_mallocfree.c:1385)
==27654== by 0x38056766: vgPlain_arena_memalign (m_mallocfree.c:1614)
==27654== by 0x3802051C: vgMemCheck_new_block (mc_malloc_wrappers.c:201)
==27654== by 0x380207CF: vgMemCheck_memalign (mc_malloc_wrappers.c:268)
==27654== by 0x38084299: vgPlain_scheduler (scheduler.c:1409)
==27654== by 0x38093684: run_a_thread_NORETURN (syswrap-linux.c:94)
sched status:
running_tid=1
Thread 1: status = VgTs_Runnable
==27654== at 0x4C249B8: memalign (vg_replace_malloc.c:581)
==27654== by 0x4C24A67: posix_memalign (vg_replace_malloc.c:709)
==27654== by 0x93E09F: av_malloc (mem.c:90)
==27654== by 0x48B756: mpegts_push_data (mpegts.c:742)
==27654== by 0x48BDFC: handle_packet (mpegts.c:1382)
==27654== by 0x48C558: handle_packets (mpegts.c:1473)
==27654== by 0x48C5C8: mpegts_read_packet (mpegts.c:1691)
==27654== by 0x4CB75E: av_read_packet (utils.c:744)
==27654== by 0x4CC566: read_frame_internal (utils.c:1222)
==27654== by 0x4CCD96: av_read_frame (utils.c:1332)
==27654== by 0x437629: main (slicer.c:630)
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The misfortune of the wise is better than the prosperity of the fool.
> -- Epicurus
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
--
---
Chris Kennedy
More information about the ffmpeg-devel
mailing list