On Thu, Aug 18, 2022 at 03:46:03PM +0200, Anton Khirnov wrote:
> The parser is internal to the demuxer, so its state at any particular
> point is not well-defined for the caller. Additionally, it is being
> accessed from the main thread, while demuxing runs in a separate thread.
> 
> Use a separate parser owned by ffmpeg.c to retrieve the same
> information.
> 
> Fixes races, e.g. in:
> - fate-h264-brokensps-2580
> - fate-h264-extradata-reload
> - fate-iv8-demux
> - fate-m4v-cfr
> - fate-m4v
> ---
>  fftools/ffmpeg.c     | 33 +++++++++++++++++++++++++++++++--
>  fftools/ffmpeg.h     |  9 +++++++++
>  fftools/ffmpeg_opt.c |  9 +++++++++
>  3 files changed, 49 insertions(+), 2 deletions(-)

This segfaults:
./ffmpeg -max_alloc 100000 -i ~/tickets/2950/mpeg2_fuzz.mpg  -max_muxing_queue_size 8000 -f null -

==25621== Invalid read of size 4
==25621==    at 0x2F3018: add_input_streams (in ffmpeg_g)
==25621==    by 0x2F3BB0: open_input_file (in ffmpeg_g)
==25621==    by 0x2FA93B: ffmpeg_parse_options (in ffmpeg_g)
==25621==    by 0x2E74B4: main (in ffmpeg_g)
==25621==  Address 0x14 is not stack'd, malloc'd or (recently) free'd

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell