{"id":1390,"date":"2009-04-27T17:07:32","date_gmt":"2009-04-28T00:07:32","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=1390"},"modified":"2009-04-27T17:07:32","modified_gmt":"2009-04-28T00:07:32","slug":"progress-on-those-crashers","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/progress-on-those-crashers\/","title":{"rendered":"Progress On Those Crashers"},"content":{"rendered":"

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\n\n\n\n\n\n\n\n\n
Result<\/th>\nDecember 8, 2008<\/th>\nApril 27, 2009<\/th>\n<\/tr>\n
Success<\/td>\n2148<\/td>\n2781<\/td>\n<\/tr>\n
FFmpeg error<\/td>\n1333<\/td>\n1389<\/td>\n<\/tr>\n
SIGABRT<\/td>\n6<\/td>\n6<\/td>\n<\/tr>\n
SIGFPE<\/td>\n376<\/td>\n1<\/td>\n<\/tr>\n
SIGKILL (timeouts)<\/td>\n16<\/td>\n17<\/td>\n<\/tr>\n
SIGBUS<\/td>\n7<\/td>\n97<\/td>\n<\/tr>\n
SIGSEGV<\/td>\n529<\/td>\n123<\/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
It would be nice to create a script that identifies that all 6 of those files suffer from the same, or similar problem and group those files together in a report. I am not sure if gdb offers non-interactive options that are conducive to this situation. I know it has a -batch mode, but I’m not really sure what that’s for. If need be, I can always create a Python script that opens gdb in interactive mode and has a stdin\/stdout conversation with it.<\/p>\n
See Also:<\/strong><\/p>\n