On 8/22/2019 4:01 PM, James Almer wrote:
> On 8/21/2019 10:21 AM, James Almer wrote:
>> On 8/21/2019 6:15 AM, Tomas Härdin wrote:
>>> tis 2019-08-20 klockan 21:05 -0300 skrev James Almer:
>>>> Should reduce date copying considerably.
>>>>
>>>> Signed-off-by: James Almer <jamr...@gmail.com>
>>>> ---
>>>> Fixed a stupid mistake when checking the return value for av_new_packet().
>>>> Still untested.
>>>
>>> Works great for me. Should make fuzzing faster overall, better use of
>>> computing resources imo
>>>
>>>> @@ -186,6 +144,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
>>>> size) {
>>>> error("Failed memory allocation");
>>>>
>>>> ctx->max_pixels = maxpixels_per_frame; //To reduce false positive OOM
>>>> and hangs
>>>> + ctx->refcounted_frames = 1;
>>>
>>> Could maybe have a comment that this is also to reduce false positives,
>>> or that we want to focus on the new API rather than the old one
>>
>> Sure.
>>
>>>
>>>> @@ -240,7 +199,10 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
>>>> size_t size) {
>>>> if (data + sizeof(fuzz_tag) > end)
>>>> data = end;
>>>>
>>>> - FDBPrepare(&buffer, &parsepkt, last, data - last);
>>>> + res = av_new_packet(&parsepkt, data - last);
>>>> + if (res < 0)
>>>> + error("Failed memory allocation");
>>>> + memcpy(parsepkt.data, last, data - last);
>>>
>>> Is there some way to avoid this copy?
>>
>> I could create packets that point to a specific offset in the input
>> fuzzed buffer, but that will mean they will lack the padding required by
>> the API, not to mention the complete lack of control over said buffer's
>> lifetime. This could either generate no issues, or make things go really
>> wrong.
>>
>> So to make proper use of the AVPacket API, i need to allocate their
>> reference counted buffers and populate them. After this patch the
>> behaviour of this fuzzer is essentially the same as if it was a
>> libavformat demuxer, creating packets out of an input file and
>> propagating them to libavcodec.
>> If the idea was to imitate an average library user's behavior, this
>> pretty much is it.
>>
>>>
>>> /Tomas
>
> Will push with the requested comment added soon.
Pushed, thanks.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
