Last December, I set about on the task of downloading<\/a> and testing a huge number of files<\/a> that were known, at one point, the crash FFmpeg<\/a>. I devised a system for automatically running the files and determining whether they still crash in FFmpeg. Quite a few of them did. Then, I sort of let the project sit.<\/p>\n I got around to running a new round of tests with the utility I created in December and compared the results with those of 4 months ago. Today’s test was conducted with FFmpeg SVN-r18707 built with “gcc: 4.0.1 (Apple Inc. build 5484)”, 32-bit version, and run on Mac OS X.<\/p>\n
| Result<\/th>\n | December 8, 2008<\/th>\n | April 27, 2009<\/th>\n<\/tr>\n |
|---|---|---|
| Success<\/td>\n | 2148<\/td>\n | 2781<\/td>\n<\/tr>\n |
| FFmpeg error<\/td>\n | 1333<\/td>\n | 1389<\/td>\n<\/tr>\n |
| SIGABRT<\/td>\n | 6<\/td>\n | 6<\/td>\n<\/tr>\n |
| SIGFPE<\/td>\n | 376<\/td>\n | 1<\/td>\n<\/tr>\n |
| SIGKILL (timeouts)<\/td>\n | 16<\/td>\n | 17<\/td>\n<\/tr>\n |
| SIGBUS<\/td>\n | 7<\/td>\n | 97<\/td>\n<\/tr>\n |
| SIGSEGV<\/td>\n | 529<\/td>\n | 123<\/td>\n<\/tr>\n<\/table>\n Great progress, especially on those floating point exceptions. I’m pretty sure nearly all of those were attributable to one or a few problems in the Real demuxer that have since been addressed. The only remaining problem in the FPE category is an AVI file.<\/p>\n The timeout category represents the number of files that ran longer than a minute (need to keep the process moving). The “FFmpeg error” category (return code 1) is on the rise. I surmise that’s because FFmpeg is getting better at rejecting errant files vs. crashing on them. I should really formulate a query that reveals which files’ status changed, and how, between runs.<\/p>\n A big reason I sat on this project for so long is that I didn’t know how to proceed. Should I start testing the problem files manually, collect stack traces, and flood the FFmpeg issue tracker with hundreds of new reports? I don’t want to deal with that kind of manual labor and I don’t think my co-devs want to deal with that volume of (possibly redundant) bug traffic.<\/p>\n Since December, I have developed another idea: Automatically running the problem files through gdb and looking for patterns. For example, I manually checked those 6 crashers that threw SIGABRT (the same 6 files from each run, BTW, and all ASF files). They all seem to fail as follows:<\/p>\n \r\nProgram received signal SIGABRT, Aborted.\r\n0x96dbbe42 in __kill ()\r\n(gdb) bt\r\n#0 0x96dbbe42 in __kill ()\r\n#1 0x96dbbe34 in kill$UNIX2003 ()\r\n#2 0x96e2e23a in raise ()\r\n#3 0x96e3a679 in abort ()\r\n#4 0x96e2f3db in __assert_rtn ()\r\n#5 0x00026529 in ff_asf_parse_packet (s=0x1002600, pb=0xa00200, \r\npkt=0xbfffe954) at \/Users\/melanson\/ffmpeg\/ffmpeg-main\/libavformat\/asfdec.c:709\r\n<\/pre>\n |