FFMPEG Issue1240

FFMPEG Issue1240

Title 	Multiple crashing bugs in processing of malformed files
Type 	bug
Priority 	important 	Status 	closed invalid
Superseder 		Nosy List
Depends On 	Crash in Indeo3 decoder, Invalid reads in VP3 decoder
View: 1482, 1483
Assigned To 		Topics

Created on 2009-06-30.18:28:54 by WD, last changed 2010-01-09.23:39:29 by cehoyos.
Files
File name 	Uploaded 	Type 	Edit 	Remove
crashdetails_noopt.zip 	WD, 2009-07-01.20:08:38 	application/zip
ffmpeg_crashers.zip 	WD, 2009-06-30.18:28:54 	application/x-zip

    Please provide full uncut output from "ffmpeg -i" if you are reporting issues with unplayable files.

Messages
msg6282 (view) 	Author: WD 	Date: 2009-06-30.18:28:54

Attached is a zip file with multiple (73) files that cause ffmpeg to crash.  The
crashers are in a subset of various codecs.  Included with each codec/directory are:
1) The seed/good file
2) Variations of the file that cause crashes (basename.x.y)
3) GDB output for the crashing testcases
4) Valgrind output for the crashing testcases
5) tabriffdump output for the crashing testcases
6) A diff summary of what is different between the crashing testcase and the
original file, RIFF-header-wise.

About half of the crashers are something that is in a RIFF header for the file
(e.g. ImageHeight, ImageWidth, dsScale, etc.)  The other half appear to be
something specific decoding of the codec.

msg6287 (view) 	Author: Vitor1001 	Date: 2009-06-30.19:53:09

Ideally one would open an issue for each file that crashes in a different way,
but since it is a lot of work I'd say to open at least a different issue for the
division-by-zero crash in AVI demuxer.

msg6288 (view) 	Author: WD 	Date: 2009-06-30.21:02:46

This is a pretty detailed report and it would be impractical for me to create
separate bug reports for each flaw.  You should have all the info that you need
right here.  If creating a separate report for each flaw helps you in tracking
the bugs and the fixes, then go right ahead.

msg6292 (view) 	Author: cehoyos 	Date: 2009-06-30.23:39:12

This issue is simply invalid.

Since somebody should test those 73 files, I mark it as important.

msg6306 (view) 	Author: Vitor1001 	Date: 2009-07-01.18:06:47

Opened issue 1245 for the division by zero in av_rescale_rnd().

msg6310 (view) 	Author: michaelni 	Date: 2009-07-01.19:26:53

On Tue, Jun 30, 2009 at 06:28:54PM +0000, WD wrote:
> Attached is a zip file with multiple (73) files that cause ffmpeg to crash.  The
> crashers are in a subset of various codecs.  Included with each codec/directory are:
> 1) The seed/good file
> 2) Variations of the file that cause crashes (basename.x.y)
> 3) GDB output for the crashing testcases

stuff like
decode_frame (avctx=0x8a25700, data=0xbfffe138,
    data_size=0xbfffe318, avpkt=0xbfffe240) at /usr/include/bits/string3.h:52

yeah it surely is in /usr/include/bits/string3.h

or
#1  0x084acdd9 in av_rescale_rnd (a=0, b=0, c=0, rnd=AV_ROUND_NEAR_INF)
#2  0x084ace2f in av_rescale (a=1, b=1, c=1) at libavutil/mathematics.c:111
they obviously match and 1 != 0

or
i = <value optimized out>

IMHO, if you do such large scale testing, it would be nice if it was actually
producing correct and useable output, as is, for some cases i cant even guess
what happened, like:
smclockmpeg1.avi.1.0
it doesnt point to any file from ffmpeg and valgrinds backtraces are pretty
terse ...

maybe you should recompile without -fomit-frame-pointer and without any
inlining and minimum optimizations and rerun these tests (x86 directory
might need more agressive flags to compile)

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides

msg6311 (view) 	Author: michaelni 	Date: 2009-07-01.20:01:32

On Wed, Jul 01, 2009 at 07:26:53PM +0000, Michael Niedermayer wrote:
> On Tue, Jun 30, 2009 at 06:28:54PM +0000, WD wrote:
> > Attached is a zip file with multiple (73) files that cause ffmpeg to crash.  The
> > crashers are in a subset of various codecs.  Included with each codec/directory are:
> > 1) The seed/good file
> > 2) Variations of the file that cause crashes (basename.x.y)
> > 3) GDB output for the crashing testcases
>
> stuff like
> decode_frame (avctx=0x8a25700, data=0xbfffe138,
>     data_size=0xbfffe318, avpkt=0xbfffe240) at /usr/include/bits/string3.h:52
>
> yeah it surely is in /usr/include/bits/string3.h

ive tried ~10 files and none of them crashes for me, also the gdb and
valgrind files are just not decipherable as they are

if someone has a reproduceable crash left a full bugreport about it is very
welcome or having these gdb/valgrind dumps regenerated with sensible compiler
flags used is welcome as well.

Except that i can just close this because i cant to anything when i cant
reproduce the problem and the information provided is junk.

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato

msg6312 (view) 	Author: WD 	Date: 2009-07-01.20:08:38

Sorry about the compiler optimization.  ffmpeg wouldn't compile by default,
complaining about impossible register constraints.  I was able to build it with
the --disable-mmx flag added, though.

Attached is a zip of the gdb and valgrind output with this build.  Should be
able to just unzip this over top of the first zip to get a valid set of files.

msg6333 (view) 	Author: reimar 	Date: 2009-07-03.11:55:02

On Tue, Jun 30, 2009 at 06:28:54PM +0000, WD wrote:
> Attached is a zip file with multiple (73) files that cause ffmpeg to crash.

A lot of these file crash no longer with SVN, please get rid of those
that work now, 73 files are simply too much to handle.

msg6375 (view) 	Author: WD 	Date: 2009-07-07.20:33:33

ffmpeg SVN-r19367 crashes with these still:

./h261/smclockh261.avi.1.0
./h261/smclockh261.avi.2.0
./h263/smclockh263.avi.1.0
./h263/smclockh263.avi.2.0
./h264/smclockh264.avi.1.0
./h264/smclockh264.avi.1.12
./h264/smclockh264.avi.2.0
./huffyuv/smclockhuffyuv.avi.1.205
./i32/smclocki32.avi.1.1
./i32/smclocki32.avi.1.201
./i32/smclocki32.avi.1.209
./i32/smclocki32.avi.1.213
./i32/smclocki32.avi.1.219
./i32/smclocki32.avi.3.1000
./i32/smclocki32.avi.3.173
./mjpeg/smclockmjpeg.avi.1.552
./mpeg1/smclockmpeg1.avi.2.1
./mpeg1/smclockmpeg1.avi.3.100
./mpeg1/smclockmpeg1.avi.3.54
./mpeg2/smclockmpeg2.avi.2.1
./mpeg2/smclockmpeg2.avi.3.54
./ogv/smclock.ogv.1.1.ogv
./ogv/smclock.ogv.1.1001.ogv
./ogv/smclock.ogv.1.101.ogv
./ogv/smclock.ogv.1.181.ogv
./ogv/smclock.ogv.2.164.ogv
./vp62/smclockvp62hsp.avi.1.0
./vp62/smclockvp62hsp.avi.3.118
./xvid/smclockxvid.avi.1.172

msg6393 (view) 	Author: WD 	Date: 2009-07-08.14:05:49

re-opening

msg6396 (view) 	Author: cehoyos 	Date: 2009-07-08.16:11:30

Since it obviously describes more than one problem, this issue is (still)
invalid. Please do not reopen, but open one new issue per crash if you care.