[FFmpeg-devel] [PATCH] Gsoc: add the two fuzzy targets

[Heng Zhang]

> 在 2021年4月22日，下午6:53，Michael Niedermayer <michael at niedermayer.cc> 写道：
> 
> On Thu, Apr 22, 2021 at 04:13:56PM +0800, Heng Zhang wrote:
>> 
>> 
>>> 在 2021年4月20日，下午7:12，Michael Niedermayer <michael at niedermayer.cc> 写道：
>>> 
>>> On Tue, Apr 20, 2021 at 12:34:13PM +0800, Heng Zhang wrote:
>>>> 
>>>> 
>>>>> 在 2021年4月19日，下午5:47，Michael Niedermayer <michael at niedermayer.cc> 写道：
>>>>> 
>>>>> On Mon, Apr 19, 2021 at 05:06:10PM +0800, a397341575 at 163.com <mailto:a397341575 at 163.com> wrote:
>>>>>> From: toseven <Byone.heng at gmail.com>
>>> [...]
>>>>>> +    if (ret < 0)
>>>>>> +    {
>>>>>> +        fprintf(stderr, "Error occurred in av_packet_add_side_data: %s\n",
>>>>>> +        av_err2str(ret));
>>>>>> +    }
>>>>>> +    return ret;
>>>>> 
>>>>> the { } placing style mismatches whats used in FFmpeg (i dont mind but some people do mind)
>>>>> 
>>>>> more general, how much code coverage is gained with these 2 fuzzers compared to what already exists ?
>>>>> 
>>>>> thanks
>>>> 
>>>> Okay, I will modify my style to adopt for FFmpeg. What is more, I didn’t compare the code coverage between them. Do I have to do this?  I mainly refer to the fate test from libavcodec/tests/avpacket.c and libavfilter/tests/formats.c.
>>> 
>>> If code coverage does not improve, what would be the reason for FFmpeg to
>>> include the code ?
>> 
>> Thank your reply. 
>> My fuzzing targets call the new API interfaces, which are not used by the existing fuzzing target. Though I don’t do the related experiment, code coverage should improve. 
> 
> Current fuzzer coverage can be seen here:
> https://storage.googleapis.com/oss-fuzz-coverage/ffmpeg/reports/20210420/linux/src/ffmpeg/report.html <https://storage.googleapis.com/oss-fuzz-coverage/ffmpeg/reports/20210420/linux/src/ffmpeg/report.html>
> 
> You are adding 2 targets
> target_avpacket_fuzzer:
> this calls
> av_packet_side_data_name, av_packet_add_side_data, av_packet_free, av_packet_clone, av_grow_packet, av_new_packet, av_packet_from_data, 
> From these all but av_packet_clone and av_packet_side_data_name are covered already
> av_packet_side_data_name() is called with a fixed argument in your code
> 
> target_formats_fuzzer:
> this calls av_get_channel_layout_string, ff_parse_channel_layout
> the first is already covered the second is in libavfilter
> libavfilter needs to be fuzzed, such fuzzing would involve building
> filter chains or networks based on fuzzer input.
> A 2nd set of libavfilter fuzzers should similar to libavcodec fuzzers
> generate 1 fuzzer generically for each avfilter similarly to how decoders
> from libavcodec are fuzzed.
> Such libavfilter fuzzers would then also test most functions within libavfilter
> 
> More generally about coverage.
> If you where in my position what would you want for additional fuzzers ?
> maximally increased coverage with mininmal effort ?
> I belive this would be achieved with generic fuzzing of filters similar to how
> decoders are fuzzed currently. But thats a bit bigger effort 
> 
> I see the gsoc page says connecting 2 fate tests to fuzzing can be used as
> qualification task. 
> For connecting such tests, the fate test and the fuzzer should use shared
> code and not duplicate. One way that can work is that the fate test takes
> some input and that input is fixed for fate but can change when used for fuzzing
> again, the more coverage we can achieve with as little effort the better.
> Basically dont be afraid to submit a small amount of code because in fact
> i would be more impressed if you can connect fate test(s) with little code
> to the fuzzer than with alot of code.
> 
> Thanks

Thank you for your patient reply. I will carefully consider your comments and submit the code again according to your suggestions.
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> While the State exists there can be no freedom; when there is freedom there
> will be no State. -- Vladimir Lenin
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at ffmpeg.org>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org <mailto:ffmpeg-devel-request at ffmpeg.org> with subject "unsubscribe".