On Tue, Mar 06, 2018 at 11:03:55PM -0300, James Almer wrote:
> On 3/6/2018 10:47 PM, Michael Niedermayer wrote:
> > On Tue, Mar 06, 2018 at 01:42:36AM -0300, James Almer wrote:
> >> This prevents leaks in the rare cases the function is called when extradata
> >> already exists.
> >>
> >> Signed-off-by: James Almer <jamr...@gmail.com>
> >> ---
> >> libavformat/utils.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index 72531d4185..31340a484b 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >> @@ -3245,6 +3245,7 @@ int ff_alloc_extradata(AVCodecParameters *par, int
> >> size)
> >> {
> >> int ret;
> >>
> >> + av_freep(&par->extradata);
> >> if (size < 0 || size >= INT32_MAX - AV_INPUT_BUFFER_PADDING_SIZE) {
> >> par->extradata = NULL;
> >> par->extradata_size = 0;
> >
> > This causes memory corruption
> > ...
> > [mpegts @ 0x7f8c74000a80] PES packet size mismatch
> > *** Error in `./ffplay': double free or corruption (fasttop):
> > 0x00007f8c7402d9c0 ***
> > Aborted (core dumped)
>
> Is something freeing extradata and leaving a dangling pointer before
> eventually calling ff_alloc_extradata()?
> At least the two calls in mpegts.c don't seem to do that.
>
> >
> > I think this should not have been applied so quickly, i tested it as soon
> > as i
> > had time and saw it but it was applied already
>
> Fate passed when i tested it, and i got a positive review from the
> author of the function in question, that's why i pushed it. Sorry.
>
> >
> > If it helps i can debug the cases i see to find out which calls cause them
> > but
> > someone will still have to review all call sites probably for this change to
> > be safe
>
> Yes, help would be welcome. Crashes like this probably hint at frees
> leaving dangling pointers across the codebase.
heres some valgrind output
==8248== Thread 15:peated 5 times
==8248== Invalid free() / delete / delete[] / realloc()
==8248== at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==8248== by 0x75B0FE: ff_get_extradata (in ffmpeg/ffplay_g)
==8248== by 0x68F1E1: ff_mp4_read_dec_config_descr (in ffmpeg/ffplay_g)
==8248== by 0x6D7A2C: m4sl_cb (in ffmpeg/ffplay_g)
==8248== by 0x6D6539: handle_packet (in ffmpeg/ffplay_g)
==8248== by 0x6D69B3: handle_packets (in ffmpeg/ffplay_g)
==8248== by 0x6D6A53: mpegts_read_packet (in ffmpeg/ffplay_g)
==8248== by 0x754AA1: ff_read_packet (in ffmpeg/ffplay_g)
==8248== by 0x75E32F: avformat_find_stream_info (in ffmpeg/ffplay_g)
==8248== by 0x4B86D8: read_thread (in ffmpeg/ffplay_g)
==8248== by 0x74742EC: SDL_RunThread (SDL_thread.c:282)
==8248== by 0x74D21A8: RunThread (SDL_systhread.c:75)
==8248== Address 0x3085a000 is 0 bytes inside a block of size 88 free'd
==8248== at 0x4C2B5D9: free (vg_replace_malloc.c:446)
==8248== by 0x68F1CD: ff_mp4_read_dec_config_descr (in ffmpeg/ffplay_g)
==8248== by 0x6D7A2C: m4sl_cb (in ffmpeg/ffplay_g)
==8248== by 0x6D6539: handle_packet (in ffmpeg/ffplay_g)
==8248== by 0x6D69B3: handle_packets (in ffmpeg/ffplay_g)
==8248== by 0x6D6A53: mpegts_read_packet (in ffmpeg/ffplay_g)
==8248== by 0x754AA1: ff_read_packet (in ffmpeg/ffplay_g)
==8248== by 0x75E32F: avformat_find_stream_info (in ffmpeg/ffplay_g)
==8248== by 0x4B86D8: read_thread (in ffmpeg/ffplay_g)
==8248== by 0x74742EC: SDL_RunThread (SDL_thread.c:282)
==8248== by 0x74D21A8: RunThread (SDL_systhread.c:75)
==8248== by 0xB8A2183: start_thread (pthread_create.c:312)
==8248==
Last message repeated 5 times
i can provide a better debug output tomorrow, need to go afk now
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
