[Ffmpeg-devel] segfault in ff_mpeg1_find_frame_end()

Michael Niedermayer michaelni
Sat May 14 17:35:19 CEST 2005


Hi

On Saturday 14 May 2005 16:29, Stefan Lucke wrote:
> On Samstag, 14. Mai 2005 12:12, Michael Niedermayer wrote:
> > Hi
> >
> > On Saturday 14 May 2005 01:57, Stefan Lucke wrote:
> > > On Samstag, 14. Mai 2005 01:37, M?ns Rullg?rd wrote:
> > > > This looks like the decoder is being fed garbage addresses to decode.
> > > >
> > > > Are you by any chance buffering AVPackets before decoding them?
> > >
> > > Yes. There are several threads. At least one for audio and one for
> > > video and some others. My guess from previous post is that
> > > parse_context.buffer is freed while another thread allocs this memory.
> > > So existing pointers into that buffer area refer to someone else.
> > > If ffmpeg is not threaded it may get the same memory locations again.
> > > So no segfault. I won't say that my commented out av_freep() is
> > > the solution. I want to say that these two lines are the causer.
>
> In mpeg_decode_frame(), function ff_combine_frame() collects incoming
> snippets into s2->parse_context . Resulting "buf" is the same as
> parse_context.buffer . This poniter is duplicated to buf_ptr and adjusted
> by
> find_start_code(). If start_code is PICTURE_START_CODE, called
> mpeg1_decode_picture() in term calls mpeg_decode_postinit() which does
> MPV_common_end() when there is a change in aspect ratio. In this function
> av_freep(&s->parse_context.buffer) is called, but mpeg_decode_frame()
> holds still pointers into that now freed area.
>
> So where is the fault in my reading of the code ?
> Or is this the (seg)fault I get ?

hmm, i think you are right, theres a bug in libavcodec
should be fixed

[...]

-- 
Michael





More information about the ffmpeg-devel mailing list